PS：图源网络，侵删勿扰
微服务不在于“微”，而在于单一职责。
采用xml或json格式达到通用，可以基于http协议或rpc协议达到服务间的轻量级通信
业务独立（开发、测试、部署） 进程隔离 持续交付技术的可扩展性（接口不依赖于特定语言和平台）性能（跨进程、跨网络、跨数据库）：考虑通信成本、网络延迟、带宽、多服务交互的响应时间
可靠性：服务数量节点增多可能带来潜在故障点，防止单点故障
异步：同步通信造成阻塞，异步通信缺增加功能实现的复杂度，出现故障时的链路追踪、定位、调试有难度。
数据一致性：保持数据一致性需要使用saga或者什么cqrs视图查询什么的
联表查询：
改造策略/原则：
最小修改（停止挖掘）
功能剥离
数据解耦
数据同步每个微服务拥有自己的数据库，这将导致部分数据冗余，但这样可以实现松耦合。
进程间通信： 服务中使用了通知、请求/响应和发布/订阅组合。
必须要加入熔断处理机制（或者设置超时、限制未完成的请求数量或提供回滚操作），否则将会造成线程堵塞无法响应。
使用异步基于消息的通信，例如使用rabbitmq、amqp等等 如何维护多个服务之间的业务事务一致性，传统的两阶段提交2pc已经不能使用 如何从多个服务中检索数据（利用事件驱动架构作为解决方案，首先发布一个事件，让与其相关的数据库所属的微服务订阅该事件，这样就导致：某个微服务内的事件被触发时，订阅该事件的微服务模块进一步触发，导致更多的事件被发布）
中间层次是消息代理
事件驱动的架构能够跨越多服务并提供最终一致性事务，另外就是能够生成和维护物化视图。
微服务重构策略：
停止挖掘以上需要两个组件，第一个为api网关，提供负载均衡、请求分发、路由控制；第二个是粘合代码，用于与单体集成，毕竟一个服务很少孤立存在，通常需要访问单体的数据库。这就需要粘合代码来负责数据集成。
提取服务创建微服务的重点是要创建低耦合的微服务，只要他们之间没有太多的直接依赖，就应该尽可能小，重要的还是要有内部一致性和对其他服务的依赖。
优势：长期敏捷性、独立部署、细粒度、高扩展、可维护、独立进行横向扩展以便节约成本。
然而，微服务架构的数据访问会变得更加复杂。即使在一个微服务或限界上下文里能够或者应该做到ACID事务一致，但每个微服务的数据是独立的，所以只能通过微服务的API来访问。将数据进行封装确保了微服务是松耦合且能独立变化的。如果多个服务访问相同数据，数据的更新就要求协调同步到所有服务，这会破坏微服务生命周期的自治性。这就表示，当业务流程跨越多个微服务时，最终一致性是唯一的办法。这比写一个简单的SQL连接要复杂得多。同理，很多其他关系型数据库功能也不支持跨微服务使用。
