SOA
SOA 是一种软件架构模式，用于构建大型的企业应用程序，这些应用程序通常要求集成多种服务，而每种服务使用不同的平台和编程语言来构建，并通过通用的通信机制进行交互。
关键点：
- SOA 是大型软件产品（如企业应用程序）的首选。
- SOA 侧重于将多个服务集成到单个应用程序中，而不是强调模块化应用程序。
- 在 SOA 中，用于服务间交互的通用通信机制被称为企业服务总线（Enterprise Service Bus，ESB）。
- 基于 SOA 的应用程序本质是单体。也就是说，单个应用程序层包含了用户界面或表示层、业务逻辑或应用程序层，以及数据库层，这些全部都集成到一个平台中。
单体应用 Vs 微服务
单体应用就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、WAR、EAR或其它归档格式。单体应用有如下优点：
- 为人所熟知
- IDE友好
- 便于共享
- 易于测试
- 容易部署
下面是单体应用的一些不足：
- 耦合，不够灵活：对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署；
- 妨碍持续交付：单体应用可能会比较大，构建和部署时间也相应地比较长，不利于频繁部署，阻碍持续交付；
- 启动速度慢
- 受技术栈限制：对于这类应用，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统，而且要使用类似的工具，无法根据具体的场景做出其它选择；
- 技术债务：“不坏不修（Not broken，don’t fix）”，这在软件开发中非常常见，单体应用尤其如此。系统设计或写好的代码难以修改，因为应用程序的其它部分可能会以意料之外的方式使用它。
而随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。
单体应用被分解成多个更小的服务，每个服务有自己的归档文件，单独部署，然后共同组成一个应用程序。
这里的“微”不是针对代码行数而言，而是说服务的范围限定到单个功能。微服务有如下特点：
- 领域驱动设计：每个团队负责与一个领域或业务功能相关的全部开发；团队拥有全系列的开发人员，具备用户界面、业务逻辑和持久化存储等方面的开发技能；
- 单一职责原则：每个服务应该负责该功能的一个单独的部分；
- 明确发布接口：每个服务都会发布一个定义明确的接口，而且保持不变；服务消费者只关心接口，而对于被消费的服务没有任何运行依赖；
- 独立设计、开发、测试、部署、维护、升级、扩展和替换；
- 可以异构/采用多种语言：每个服务的实现细节都与其它服务无关，这使得服务之间能够解耦，团队可以针对每个服务选择最合适的开发语言、持久化存储、工具和方法；
- 轻量级通信：服务通信使用轻量级的通信协议，例如，同步的 REST，异步的 AMQP、STOMP、MQTT等。
相应地，微服务具有如下优点：
- 易于开发、理解和维护；
- 比单体应用启动快；
- 局部修改很容易部署，有利于持续集成和持续交付；
- 故障隔离，一个服务出现问题不会影响整个应用；
- 不会受限于任何技术栈。
- 可以构建全自动的部署机制，确保个体服务的部署、服务管理和自动伸缩。
微服务 Vs SOA
从核心需求来讲，微服务架构和 SOA 区别并不是特别大。但微服务有个比较重要的点，就是可以独立部署，独立发展，这是跟 SOA 最主要的区别。服务可以独立部署就更容易快速迭代，这也是微服务要解决的一个问题。
- 微服务架构和 SOA 虽然不一样，但它们确实存在一些相似之处。微服务架构被称为 SOA 的变体，甚至是 SOA 的一种特殊化。换句话说，SOA 可以被认为是微服务架构的超集。
- 人们之所以能够在这些架构之间找到相似性，主要是因为它们都专注于构建具有松散耦合的服务。这些服务具有明确的界限，并且每个服务都具有独立的功能集。
- 不同之处在于，SOA 可能意味着其他很多东西。例如，SOA 适用于单体架构，重点是将系统集成在一个应用程序中，并确保代码的可复用性。但对微服务架构来说并不是这样的，微服务架构的重点是通过构建独立服务和确保产品的可伸缩性来模块化应用程序。
微服务架构的不足
- 微服务把一个服务拆分成了很多个，维护的对象就变多了。维护对象变多之后，如果一个任务出现问题，将很难定位出现问题的节点。
- 微服务化开发需要熟悉微服务开发框架、中间件，需要考虑失效、容错等策略，给开发也带来了新的挑战。
- 微服务如果拆分不好，会大量引入分布式事务，处理起来会比较麻烦。
- 微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。
- 分区的数据库架构。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。
- 测试一个基于微服务架构的应用也是很复杂的任务。
微服务会极大地增加运维工作量，InfoWorld在一篇文章中明确指出：
使用微服务，一些技术债务势必从开发转到运维，因此，你最好有一个一流的开发运维团队。
因此，微服务对基础设施提出了一些额外的需求。通常，我们将它们总称为NoOps，本质上讲，就是一组服务，提供一个更好的应用程序部署流程并确保其运行，包括服务复制、服务发现、服务恢复和服务监控。
微服务拆分原则
在微服务拆分中，核心的需求在于拆开的微服务之间的联系越少越好，虽然我们强调复用，但是联系越少越好，数据交互也是越少越好。因为微服务之间的数据一致性非常难处理，如果一致性方面的问题很少，整体做起来就比较简单了。
微服务架构选型
现在比较火的是 Spring Cloud。
参见文集：https://www.jianshu.com/nb/9740072
微服务架构的设计模式
聚合器 Aggregator 微服务设计模式
聚合器调用多个服务实现应用程序所需的功能。
它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。
代理 Proxy 微服务设计模式
在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
链式微服务设计模式
在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。
分支微服务设计模式
这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示：
数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。
但在重构现有的单体应用时，SQL数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，如下图所示：
在这种情况下，部分微服务（例如 C 和 D）可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。
异步消息传递微服务设计模式
虽然 REST 设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示
微服务与Docker
关于 Docker，参见 Docker 学习笔记
Docker 是全球领先的软件容器化平台，它将微服务封装进我们所说的 Docker 容器，然后进行独立的维护和部署。每个容器都将负责一个特定的业务功能。
以电子商务网站为例。我们知道它拥有多项业务和服务，例如创建账号、显示产品目录、建立和验证购物车等。在微服务架构中，所有这些都可以视为微服务并封装在 Docker 容器中。但是，为什么要这样做？
其中一个原因是为了确保开发和生产环境之间的一致性。例如，假设有三位开发人员正在开发此应用程序，他们每个人都有自己的开发环境。其中一个开发人员可能在他的机器上运行 Windows 操作系统，而第二个开发人员可能运行 Mac OS，第三个开发人员会更喜欢基于 Linux 的操作系统。他们每个人都需要花费数小时的时间将应用程序安装到各自的开发环境中，并且需要做额外的工作将它们部署到云端。这一过程并不那么顺畅，在将这些应用程序部署到云基础设施上时，他们之间总是会发生摩擦。
借助 Docker，可以使应用程序独立于主机环境。因为采用了微服务架构，所以现在可以将每个服务封装到 Docker 容器中。Docker 容器是轻量级的，并且资源是隔离的，通过它可以构建、维护、发布和部署应用程序。
优点：
- Docker 是一款非常流行的软件，有强大的社区支持，并专门为微服务而构建。
- 与虚拟机相比，它是轻量级的，在成本和资源消耗方面颇具优势。
- 它为开发和生产环境提供了一致性，非常适合用于构建云原生应用程序。
- 它为持续集成和部署提供了便利。
- Docker 可与 AWS、Microsoft Azure、Ansible、Kubernetes、Istio 这些流行的工具和服务集成。
引用：
单体应用与微服务优缺点辨析
微服务架构的设计模式
微服务实战（一）：微服务架构的优势与不足
权衡取舍：企业落地微服务避坑指南
Docker和微服务的崛起
