微服务架构与SOA的比较

SOA (Service-Oriented Architecture ）即面向服务架构，是一种粗粒度、松藕合的面向服务架构设计方法。SOA 可以看作 BIS 模型、 XML/Web Service 技术之后的自然延伸。

SOA 是一种企业级的架构设计方法，使用企业服务总线 (ESB ）的方式，构建一个能够更高效、更可靠、更具重用性的企业信息系统。相比于 C/S BIS 等模式的设计，使用 SOA 架构的系统已经取得了很大的进步，系统可以更加从容地面对业务的急剧变化，所以 SOA 曾经风靡一时，例如 Dubbo Dubbox Mule WS02 CXF 等都是较为优秀的 SOA 开源工具。

微服务架构与 SOA 从表面上看是有一点相似的，以至于早期有人认为微服务就是一个细粒度的 SOA。实际上，它们的区别还是很大的。

区别之一：微服务通信的轻量级设计与 SOA 重量级设计。这也是两种架构的最大区别。微服务的通信设计使用简单的 HT霄，一般基于 REST 协议实现。而 SOA 一般使用复杂的协议，如WebService BPEL (Business Process Execution Language ，业务流程执行语言〉等，还需要使用服务描述性语言来定义标准接口。

区别之二：微服务的自治性与 SOA 的集中式管理。微服务架构使用去中心化的扁平化管理方式，每个服务都是一个独立的应用程序独立管理、使用独立的数据库、独立部署和独立运行。SOA 是一种整体式架构，使用集中式的管理方式和统一的数据中心。所以微服务的开发和部署更加灵活和快速，可以更快地响应需求的变化和业务的更新。

区别之三：SOA 与微服务架构的应用的规模不同， SOA 是在企业计算领域中产生的一种架构设计方法，在应用规模上的范围有限。而微服务架构是产生于互联网环境中的一种设计方法，它更能适应无限广阔的环境，以及互联网高流量、高并发的规模扩展。

微服务架构的高可用设计、自由伸缩、负载均衡、故障转移等特性是 SOA 设计不够重视的地方。微服务的高可用设计通过微服务治理，为每个微服务的管理和部署提供了一个可以扩展的无限广阔的空间，它可以表现为一个三维结构，如图 1-3 所示。

在这个三维结构中，如果我们用Y 轴表示微服务应用，用X 轴表示微服务应用副本，用Z轴表示微服务治理，那么它将提供服务路由和负载均衡管理等功能。如果有需要，它还可以提供分区管理的功能。这种三维结构让微服务天生就具备了自由伸缩的条件，以及可以进行无限扩展的能力。

微服务架构的优势

从前面的比较可以看出，整体式架构已经不适合于一个大型项目或者一个互联网应用平台的开发了，而 SOA 架构虽然曾经风靡一时，但是其重量级的设计成为快速开发的障碍，所以这两种架构都将被微服务架构取代。微服务架构轻量级的设计风格，不管是从理论上，还是从技术实现上，已经越来越多地得到人们的肯定和认可，大家对它的未来发展趋势都抱有一种乐观的态度。微服务的优势如下

第一，开发简单。

微服务架构把复杂系统进行拆分之后，让每个微服务应用的开发都变得非常简单。对于开发者来说，因为不用针对很多代码进行分析，所以效率会成倍地提高。

第二，快速响应需求变化。

一般的需求变化都来自局部功能的变更，这种变更将落实到每个微服务上，而每个微服务的功能相对来说都非常简单，更改起来非常容易，所以微服务非常适合使用敏捷开发方法，能快速响应业务需求的变化。

第三，随时随地更新。

一方面，一个微服务的部署和更新并不会影响全局系统的正常运行，另一方面使用多实例的部署方式可以做到一个服务的重启和更新在不被察觉的情况下进行。所以，每个微服务在任何时候都可以进行部署和更新

第四，系统更加稳定可靠。

微服务运行在一个高可用的分布式环境之中，有配套的监控和调度管理机制，并且还可以提供自由伸缩的管理，充分保障了系统的稳定性和可靠性。

第五，规模可持续扩展。

每个互联网应用都具有巨大的市场潜力，一旦这种潜力被激发，就需要系统能支持大规模的高并发访问。使用微服务架构设计的系统，可以适应业务的快速增长，并且可持续支持规模化的扩展。

为实施微服务架构做好准备

微服务架构不是种新技术，它只是一种全新的设计理念，所以，为了能够更好地实施微服务架构设计，我们必须做好前期准备，从思想观念、团队管理和自动化基础设施上进行相应的变革。

思想观念

在进入微服务领域之前，必须从做项目的观念转变成做产品的观念。如果是一个软件项目，在完成了业务需求的设计之后，最终交付使用，其项目开发的生命周期就宣告结束。而做产品则完全不一样，只要产品成型上线，产品有存在的价值，开发就永远没有终结。随着产品的更新换代，其中的应用程序和组件也要跟不断地进行更新和迭代。

微服务架构的渐进式设计的特，就是一种做产品的观念的实体现。一方面，一个产品的最初成型设计，由于种种原因并不可能把所有功能都考虑得很周到，这需要一定的时间进行慢慢的磨合与创新。另一方面，市场总是处于变化之中，所以产品的业务功能也会随着时间的推移而发生定的变化。

做产品的观念将贯穿于一个系统平台的整个生命周期之中，并随着平台的发展和演化，最终将产品打造成一个充满活力的生态体系。

团队管理

传统的团队管理，是按技术进行分组的。在一个开发团队中，可能有设计组、前端开发组、后端开发组、测试组和运维组等。

在微服务架构实施中，开发时是按业务功能进行划分的，所以对团队的管理，最好也以业务进行分组，将产品设计、前端开发、后端开发、测试和运维等人员围绕业务功能分配在同组中，这样不但可以增强团队的凝聚力，还可以避免将大量的时间浪费在不同组别的沟通和工作协调上。

在实际操作中，因为前端开发和运维管理的消耗不是很大，所以对这两部分人员可以进行机动的调整。但这种调整最好是在业务相近的领域中进行的，并保持一定的连贯性，即原来由谁负责的工作，在更新和维护时还是由他来负责。

为了减少资源的浪费和增加每个人员的工作饱和度，一个业务小组往往并不只负责一个微服务，有可能负责两三个微服务的开发，这主要由微服务划分的粗细粒度来定。

自动化基础设施

从整体式架构向微服务架构转变之后，项目数量会增加，迭代的周期会变短，对测试和运维人员也会提出更高的要求，并且其工作量会越来越大，所以单纯依靠人力来完成这两部分的工作是远远不够的，这就要求必须有自动化基础设施的支持，来完成自动集成、自动测试，以及持续交付、持续部署的工作。

一个原来由几个项目支撑起来的应用平台，在使用微服务架构进行拆分之后，可能会变成几十个项目，甚至上百个项目。如果还像原来那样分配测试和运维工作，则势必要增加更多的人员。

在服务器资源的使用上，也会相应的有所增加。因为每个微服务应用所占用的资源并不是很大，所以可以在原来的服务器中使用虚拟机技术扩展服务器群组。对于微服务的部署，我们将主要以 Docker 容器为主导，使用虚拟化技术实施自动化建设，这样可以非常自由地将微服务分散部署在分布式环境之中。而对于中小型企业来说，更好的实施方案是使用云计算服务商提供的资源，这样能更有效地利用服务器的资源。