标签：负载 持续集成 操作系统 users 编程 包含 合并 产生 分布
面向服务的架构（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的系统。如果你开发的是互联网应用，并且没有历史遗留问题，请优先考虑采用微服务架构。
 功能 |
SOA | 微服务 |
|---|---|---|
| 系统划分 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 系统通信 | ESB | 统一的协议标准 |
| 服务交付 | 手工交付 | 自动化快速交付 |
| 适用场景 | 企业内部 | 互联网应用 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 扩展 | 难扩展 | 单个服务很容易横向扩展 |
更多精彩文章
标签：负载 持续集成 操作系统 users 编程 包含 合并 产生 分布
原文地址：https://blog.51cto.com/zhanlang/2541481
