关于微服务:为什么有了SOA我们还用微服务

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同性能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约分割起来。接口是采纳中立的形式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的零碎中的服务能够以一种对立和通用的形式进行交互。它是一种设计办法，其中蕴含多个服务，服务之间通过相互依赖最终提供一系列的性能。

微服务架构: 其实和 SOA 架构相似, 微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务须要彻底的组件化和服务化”，原有的单个业务零碎会拆分为多个能够独立开发、设计、运行的小利用。这些小利用之间通过服务实现交互和集成。

基于 SOA 架构的零碎，模块在进行划分的时候，颗粒度比拟粗，比方一个会员零碎 SOA，可能蕴含会员根本信息管理，会员关系治理，会员资产治理等模块，这些模块统一规划在会员治理服务，部署的时候也在雷同的过程中。如果依照微服务的理念来做架构设计的话，会员关系治理可能会是一个独立部署的服务，其余模块相似。是否须要独立，架构师须要依据这个模块的业务来决定，须要考查这个模块是否有独立的必要性。

有的时候，一个零碎的畛域边界划分在 SOA 和微服务中可能雷同。SOA 和微服务实质上有着雷同的架构思维，然而微服务依据业务状态又引入了组件化和领域建模的架构理念，在少数的利用场景中比 SOA 有着更易保护，扩大不便的长处。

无论是 SOA 还是微服务架构，都是零碎倒退到肯定水平衍生而出的一种解决方案，都是为了解决零碎存在的弊病而产生的架构计划。当零碎一开始采纳集中化部署的时候，随着零碎模块越来越多，自然而然就产生了拆分的计划。
无论是 SOA 还是微服务架构都是依据业务进行拆分的后果，然而他们又有着很多不同。

服务通信

在 SOA 零碎架构中，服务之间的调用采纳 ESB（企业服务总线）来进行通信。ESB 负责服务定义、服务路由、音讯转换、消息传递，总体上是重量级的实现。简略来说 ESB 就是一根管道，用来连贯各个服务节点。

微服务强调应用对立的协定和格局，例如，RESTful 协定、RPC 协定，毋庸 ESB 这样的重量级实现。也有的零碎为了对立治理微服务零碎，会部署一个对立的网关零碎，网关是零碎的惟一入口。从面向对象设计的角度看，它与外观模式相似。网关封装了零碎外部架构，为每个客户端提供一个定制的 API。它可能还具备其它职责，如身份验证、监控、负载平衡、缓存、申请分片与治理、动态响应解决。网关形式的外围要点是，所有的客户端和生产端都通过对立的网关接入微服务，在网关层解决所有的非业务性能，每个服务都须要去服务管理中心去被动注册，这样能力实现服务的主动发现。

服务划分粒度

整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个大型企业来说，“员工管理系统”就是一个 SOA 架构中的服务；而如果采纳微服务架构，则“员工管理系统”会被拆分为更多的服务，比方“员工信息管理”“员工考勤治理”“员工假期治理”和“员工福利治理”等更多服务。
至于微服务的粒度要到什么水平，仁者见仁，智者见智，有的小伙伴说直到服务不能拆分为止，其实我认为这种想法是错的，一个微服务的拆分粒度，还是要依据你的具体业务来划分，依据你的依赖模块关系来划分，不要自觉拆分成太多颗粒度小的服务，这样在治理上会给团队带来很多困扰。举一个简略例子：员工管理系统中，如果考勤治理和假期治理之间业务关系十分亲密，而且有很多操作须要事务性原子操作，你能够思考将这两个微服务合并。

SOA 激励组件的共享，而微服务尝试通过“上下文边界”来最小化共享。

服务交付

无论是 SOA 还是微服务，每个独立的零碎都能够采纳不同的编程语言来开发，只有对外提供的接口协议符合标准就能够。在开发方面，因为微服务会采纳划分粒度更小的策略，所以理论状况中服务的数量会比 SOA 架构形式要多很多，微服务的架构理念要求“疾速交付”，相应地要求采取自动化测试、继续集成、自动化部署等麻利开发相干的最佳实际。如果没有这些根底能力撑持，微服务规模一旦变大（例如：超过 20 个微服务），整体就难以达到疾速交付的要求，这也是很多企业在履行微服务时踩过的一个显著的坑，就是零碎拆分为微服务后，部署的老本呈指数回升。

如果企业外部疾速交付的基础设施比拟单薄，采纳微服务架构形式前期兴许会遇到部署老本的问题。

实用场景

微服务适宜那些须要疾速交付，比拟轻量级的互联网利用。古代互联网变动迅速，每个零碎都须要疾速尝试，疾速交付，这也是产生微服务架构的次要起因之一。因为每个服务都能够独自部署，所以在那些大并发的状况下，更容易横向扩大，就算是某个服务 down 掉，也不会影响其余的服务失常运行。而 SOA 因为 ESB 的存在，一旦 ESB 挂掉，会影响到所有零碎失常运行。

SOA 相比拟微服务，更适宜那些访问量较小，然而业务体系宏大，简单的企业级零碎。当一个企业级的零碎倒退到肯定水平，SOA 会应运而生，而且这个零碎还会连续很长时间，期间还会采纳不同的技术栈来开发不同的零碎，这些零碎会一直集成进来，如果想要推倒重来或者进行大规模的优化，人力物力上基本得失相当，所以这样的零碎只能以兼容的形式持续，而承当各个异构零碎通信的重要组件就是 ESB。

SOA 和微服务实质上是两种不同的架构设计理念，即便他们在服务这个概念和划分思维上有交加。因为是两种不同的架构模式，所以在利用上并不存在孰优孰劣，只有是否适合之分。具体采纳哪种架构设计，最终还是要取决于你的利用场景和目标。SOA 更适宜须要与许多其余应用程序集成的大型简单企业应用程序环境。这就是说，小型应用程序不适宜 SOA 架构，因为它们不须要消息中间件组件。而微服务架构，在另一方面，是更适宜于较小和良好的宰割，基于 Web 的零碎。如果你开发的是互联网利用，并且没有历史遗留问题，请优先思考采纳微服务架构。

更多精彩文章

• 分布式大并发系列
• 架构设计系列
• 趣学算法和数据结构系列
• 设计模式系列