1. SOA 服务化架构
SOA 是一种粗粒度、松耦合的以服务为中心的架构，接口之间通过定义明确的协议和接口进行通信。SOA 帮助工程师站在一个新的高度理解企业级架构中各种组件的开发和部署形式，可以帮助企业系统架构以更迅速、可靠和可重用的形式规划整个业务系统。相比传统的非服务化架构，SOA 能够更加从容地应对复杂企业系统集成和需要的快速变化。
1.1 SOA 设计的原则
SOA 面向服务的一般原则总结如下
- 服务可复用：不管是否存在即时复用的机会，服务均被设计为支持潜在的可复用
- 服务共享一个标准契约：为了与服务提供者交互，消费者需要导入服务提供者的服务契约，这个契约可以是一个 IDL 文件、Java 接口定义、WSDL 文件，甚至是个接口说明文档
- 服务是松耦合的：服务被设计为功能相对独立、尽量不依赖其他服务的独立功能提供者
- 服务是底层逻辑的抽象：只有经服务契约所暴露的服务对外部世界可见，契约之外底层的实现逻辑是不可见的
- 服务是可组合、可编排的：多个服务可能被编排组合成一个新的服务，这允许不同逻辑抽象的自由组合，促进服务的复用
- 服务是自治的：逻辑由服务所控制，并位于一个清晰的边界内，服务已经在边界内被控制，不依赖其他服务
- 服务是无状态的：服务应当不需要管理状态信息，因此能够维持送耦合性。服务应该被尽可能设计成无状态，即便这意味着要将状态管理移至他处
- 服务是可被自动发现的：服务发布上线后，允许被其他消费者自动发现；当服务提供者下线后，允许消费者接收服务下线通知。
1.2 服务治理
SOA 服务化之后，应用服务化之后给系统运维带来很大挑战：
- 分布式框架下的服务调用性能
- 服务化架构如何支持线性扩展
- 如何实现高效、实时的服务多维度监控
- 大规模分布式环境下的故障快速定界和定位
- 分布式环境下海量日志在线检索、模糊查询
- 服务的流控、超时控制、服务升降级等管控手段
- 服务的划分原则，如何实现最大程度复用
- ……
此时，SOA 服务治理是关键。SOA 服务治理主要包括如下几个方面：
- 服务定义：SOA 治理最基础的方面就是监视服务的创建过程。必须对服务进行标识，描述其功能，确定其行为范围并设计其接口。创建服务时需要与使用这些服务的团队进行协调，以确保服务能够满足消费者需求，避免重复工作。
- 服务生命周期管理：服务的生命周期通常有五个主要的阶段。
- 计划阶段
- 测试阶段
- 运行阶段
- 弃用阶段
- 废弃阶段
- 服务版本治理：新版本的前向兼容性，灰度发布等需要按照统一的策略进行管理。
- 服务注册中心：需要统一的服务注册中心支持服务的订阅发布和动态发现机制。
- 服务监控：服务监控中心需要对服务的调用时延、成功率、吞吐率等数据进行实时采样和汇总，通过图形化报表的形式展示，以便运维人员对服务的运行质量进行实时分析和掌控。
- 运行期服务质量保障：包括服务限流、服务迁入迁出、服务升降级、服务权重调整和服务超时控制等，通过运行期的动态治理，可以在不重启服务的前提下达到快速提升服务运行质量的目标。
2. 微服务架构
微服务架构（MSA）是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦。
2.1 什么是微服务
微服务架构的主要特征如下：
- 原子服务：单一职责，“高内聚，松耦合”。
- 高密度部署：重要的服务可以独立进程部署，非核心服务可以独立打包，合设到同一个进程中，服务被高密度部署。物理机部署，可在一台服务器上部署多个服务实例进程；如果是云端部署，则可以利用 LXC 实现容器级部署，以降低部署成本，提升资源利用率。
- 敏捷交付：真正的 DevOps。
- 微自治：服务足够小，功能单一，可以独立打包、部署、升级、回滚和弹性伸缩，不依赖其他服务，实现局部自治。
2.2 微服务架构对比 SOA
两者的主要差异如下：
- 服务拆分粒度：SOA 首先要解决的是异构系统应用的服务化；微服务强调的是服务拆分尽可能小，最好是独立的原子服务。
- 服务依赖：传统的 SOA 服务，由于需要重用已有的资产，存在大量的服务间依赖；微服务的设计理念是服务自治、功能单一独立，避免依赖其他服务产生耦合，耦合会带来更高的复杂度。
- 服务规模：传统 SOA 服务粒度比较大，多数会采用将多个服务合并打成 war 包的方案，因此服务实例数比较有限；微服务强调尽可能拆分，同时很多服务会独立部署，这将导致服务规模急剧膨胀，对服务治理和运维带来新的挑战。
- 架构差异：微服务化之后，服务数量的激增会引起架构质量属性的变化，例如企业集成总线 ESB 逐渐被 P2P 的虚拟总线替代；为了保证高性能、低时延，需要高性能的分布式服务框架保证微服务架构的实施。
- 服务治理：传统基于 SOA Governance 的静态治理转型为服务运行态微治理、实时生效。
- 敏捷交付：服务由小研发团队负责微服务设计、开发、测试、部署、线上治理、灰度发布和下线，运维整个生命周期支撑，实现真正的 DevOps。
- 快速的故障定界定位手段：故障定界定位主要包括两方面的内容。
- 大规模分布式环境下海量业务/平台日志的采集、汇总和实时在线检索，支持多维度的条件检索、模糊查询，可以快速的在线查看各种系统运行日志，方便问题定位；
- 分布式消息跟踪，通过调用链打通业务、服务调用和异常，发现线上系统故障源；通过在线和离线调用链大数据分析，得到链路各个依赖的稳定性指标，梳理依赖链路风险表，识别系统核心功能的服务调用依赖关系，评估可能的最大风险点，针对性改进以预防风险，同时为容量规划和扩容提供数据决策依据。
- 服务安全：服务调用必须能够提供安全功能，对服务的访问进行权限控制，将服务的访问权限仅限于授权使用者。服务安全访问策略有多种，例如可以通过动态生成令牌（Token）的方式做安全访问授权，服务提供者动态生成 Token 并告知服务注册中心，由注册中心告知是否告知消费方，这样就能在注册中心页面上做复杂的授权模型。
总结：量变引起质变，这就是微服务架构和 SOA 服务化架构的最大差异。