增大系统容量、加强系统可用。
优势:
因为模块化,所以系统模块重用度更高;
因为软件服务模块被拆分,开发和发布速度可以并行而变得更快;
系统扩展性更高。
缺点:
架构设计变得复杂,部署单个服务会比较快,但是如果一次部署需要多个服务,部署会变得复杂。
架构复杂导致学习曲线变大、测试和查错的复杂度增大、维护和运维的复杂
管理服务和调度变得困难和复杂。

分布式系统的发展
开发、维护和使用 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 层的支撑,微服务也是很难被管理和运维的。
网友评论