分布式系统架构的冰与火

增大系统容量、加强系统可用。

优势：

因为模块化，所以系统模块重用度更高；

因为软件服务模块被拆分，开发和发布速度可以并行而变得更快；

系统扩展性更高。

缺点：

架构设计变得复杂，部署单个服务会比较快，但是如果一次部署需要多个服务，部署会变得复杂。

架构复杂导致学习曲线变大、测试和查错的复杂度增大、维护和运维的复杂

管理服务和调度变得困难和复杂。

分布式系统的发展

开发、维护和使用 SOA 要遵循以下几条基本原则。

可重用，粒度合适，模块化，可组合，构件化以及有互操作性。

符合开放标准（通用的或行业的）。

服务的识别和分类，提供和发布，监控和跟踪。

但 IBM 搞出来的 SOA 非常重，所以对 SOA 的裁剪和优化从来没有停止过。比如，之前的 SOAP、WSDL 和 XML改成了 RESTful 和 JSON 这样的方式。 ESB简化成了 Pub/Sub 的消息服务……

不过，SOA 的思想一直延续着。所以，我们现在也不说 SOA 了，而是说分布式服务架构了。

下面是一个 SOA 架构的演化图。

我们可以看到，面向服务的架构有以下三个阶段。

90 年代前：单体架构，软件模块高度耦合。

2000 年：松耦合的 SOA 架构，这个架构需要一个标准的协议或是中间件来联动其它相关联的服务（如 ESB）。这样一来，服务间并不直接依赖，而是通过中间件的标准协议或是通讯框架相互依赖。这其实就是 IoC（控制反转）和 DIP（依赖倒置原则）的设计思想在架构中的实践。它们都依赖于一个标准的协议或是一个标准统一的交互方式，而不是直接调用。

2010 年后：微服务架构更为松耦合。独立完整地运行，后端单体的数据库也被微服务这样的架构分散到不同的服务中。和传统 SOA 的差别在于，服务间的整合需要一个服务编排/整合的引擎。就好像交响乐中需要有一个指挥来把所有乐器编排和组织在一起。

这个编排和组织引擎可以是工作流引擎，也可以是网关。还需要辅助于像容器化调度这样的技术方式，如 Kubernetes。在 Martin Fowler 的Microservices 这篇文章中有详细描述。

在集成测试、运维和服务管理等方面就比较麻烦了。所以，需要一套比较好的微服务 PaaS 平台。就像 Spring Cloud 一样需要提供各种配置服务、服务发现、智能路由、控制总线……还有像 Kubernetes 提供的各式各样的部署和调度方式。

没有这些 PaaS 层的支撑，微服务也是很难被管理和运维的。