012 云原生之微服务

SOA 早期使用的是总线模式，这种总线模式与某种技术栈具有强绑定关系，导致很多企业的遗留系统很难对接，且切换时间太长，成本太高，新系统稳定性的收敛也需要一段时间。为了摆脱这一困境，微服务应运而生。作为 SOA 的变体，微服务将应用程序构造为一组松散耦合的服务。在微服务体系架构中，服务是细粒度的，协议是轻量级的。

过去开发一个后端应用最直接的方式就是，通过单一后端应用提供并集成所有的服务，即单体模式。

微服务模式将后端单体应用拆分为多个松耦合的子应用，由每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”将共同形成一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程来提高整体迭代效率。

在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，以保障应用的弹性、可用性和安全性。应用构建在云平台所提供的基础设施与基础服务之上，充分利用云服务所带来的便捷性和稳定性，可以降低应用架构的复杂度。云原生的微服务体系也将帮助应用架构全面升级，让应用具备更好的可观测性、可控制性、容错性等。

一个设计良好的微服务应用，所完成的功能在业务域的划分上应相互独立。与单体应用强行绑定语言和技术栈相比，这样做的好处是不同的业务域拥有不同的技术选择权，比如，推荐系统采用 Python 的实现效率可能比采用 Java 的要高很多。

微服务的可发现性是指，当服务 A 发布或扩缩容时，依赖服务 A 的服务 B 如何在不重新发布的前提下自动感知到服务 A 的变化。这里需要引入第三方服务注册中心来满足服务的可发现性；特别是对于大规模微服务集群来说，服务注册中心的推送和扩展能力尤为关键。

微服务的可交互性是指，服务 A 需要采用什么样的方式才可以调用服务 B。由于服务自治的约束，服务之间的调用需要采用与语言无关的远程调用协议。

微服务领域提倡数据存储隔离（Data Storage Segregation，DSS）原则，即数据是微服务的私有资产，必须通过当前微服务提供的 API 来访问数据，否则数据层就会产生耦合，违背高内聚低耦合的原则。同时，出于性能考虑，建议采取读写分离方式，分离高频的读操作和低频的写操作。

第三代微服务架构就是云原生时代的微服务（Cloud NativeMicroservice）架构，边车进程开始接管微服务应用之间的流量，承载第二代微服务架构中服务框架的功能，包括服务发现、调用容错以及丰富的服务治理功能，例如权重路由、灰度路由、流量重放、服务伪装等。

在第四代微服务架构中，微服务由一个应用进一步简化为微逻辑（Micrologic），这也对边车模式提出了更高要求，更多可复用的分布式能力从应用中剥离，并下沉到边车中，例如状态管理、资源绑定、链路追踪、事务管理、安全等。

Dubbo 作为一个分布式服务框架及 SOA 治理方案，其功能主要包括高性能 NIO（New IO）通信及多协议集成、服务动态寻址与路由、软负载均衡与容错、依赖分析与服务降级等。Dubbo 的最大特点是按照分层的方式来架构，使用这种方式可以使各层之间解耦合（或者最大限度地松耦合）。