SOA架构

SOA（Service-Oriented Architecture，面向服务的架构）是一种高层级的 架构设计理念，可通过在网络上使用基于通用通信语言的服务接口，让软件组件可重复使用。它使用称为服务的软件组件来创建业务应用程序。每项服务提供一种业务能力，并且服务也可以跨平台和语言相互通信。开发人员使用 SOA 来重用不同系统中的服务，或者组合几个独立的服务来执行复杂的任务。

ESB（Enterprise Service Bus，企业服务总线）把企业中各个不同的服务连接在一起。就像计算机总线一样，把计算机的各个不同的设备连接在一起。

因为不同的服务是使用不同的技术实现的，各个独立的服务是异构的，如果没有统一的标准，则各个异构系统对外提供的接口是各式各样的。SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。ESB通过使用标准网络协议（如 SOAP、XML、JSON、MQ ）来开放服务以发送请求或访问数据，实现与各种系统间的协议转换、数据转换、透明的动态路由等功能，消除了开发人员必须从头开始进行集成的困扰。

采用 SOA 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖，减少各个服务间的依赖和互相影响，做到了松耦合。

如果做不到松耦合，某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。

SAO架构的局限性

企业服务总线（ESB）将多个服务连接在一起，这使其成为单一故障点。
所有服务共享一个公用数据存储库。这使得服务难以单独管理。
每项服务的范围都很广。因此，如果其中一项服务出现故障，整个业务工作流程都将受到影响。

微服务架构

微服务（Microservices）是一种 软件架构风格，由 SOA 架构风格演变而来，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。

微服务架构风格是一种将 单体应用开发为一套 小型服务的方法，每个服务都在自己的进程中运行，并使用 轻量级的通信机制（通常是 HTTP 类型的 API）进行通信。这些服务是围绕 业务能力构建的，并且可以通过 全自动化的部署机制 进行 独立部署。这些服务可以用 不同的编程语言编写，也能使用不同的 数据存储技术。—— 2014 ，由Martin Fowler 与 James Lewis提出

微服务架构的优势

快：更注重敏捷开发、持续交付
准：服务粒度小、服务质量精准可控
狠：适用于互联网时代，产品迭代周期更短

微服务架构带来的挑战

分布式系统的复杂性
服务依赖管理
数据的一致性保障
测试更加艰难
对DevOps等基础设施的高要求

如何进行服务划分

按业务职能（Business Capability）划分
由公司内部不同部门提供的职能。例如客户服务部门提供客户服务的职能，财务部门提供财务相关的职能。
按 DDD 的限界上下文（Bounded Context）划分
限界上下文是 DDD 中用来划分不同业务边界的元素，这里业务边界的含义是 解决不同业务问题的问题域和对应的解决方案域，为了解决某种类型的业务问题，贴近领域知识，也就是业务。
CQRS 将系统中的操作分为两类，即 命令（Command）与 查询（Query）。
命令是对会引起数据发生变化操作的总称，即我们常说的新增，更新，删除这些操作，都是命令。而查询则和字面意思一样，即不会对数据产生变化的操作，只是按照某些条件查找数据。CQRS 的核心思想是将这两类不同的操作进行分离，然后在两个独立的「服务」中实现。这里的「服务」一般是指两个独立部署的应用。在某些特殊情况下，也可以部署在同一个应用内的不同接口上。

微服务发展历史

第一代：基于RPC的传统服务架构

第二代：Service Mesh（以Istio为代表的服务网格模式）

微服务架构分层

微服务核心组件

API网关
服务注册中心
配置中心
服务通信
服务治理
服务监控

SOA架构与微服务架构对比

	SOA	微服务
服务粒度	粗粒度	细粒度
业务划分方式	水平多层	纵向业务划分
部署方式	整体部署	独立部署
通信方式	使用重量级通信方式，ESB充当服务之间通信的角色	使用轻量级通信方式，如HTTP RESTful
服务交付	交付慢	交付快
应用场景	庞大、复杂、异构的企业级系统	快速、轻量级、基于 Web 的互联网系统