关于微服务架构的定义众说纷纭，因此我摘取了几个描述的比较清晰的定义在这供参考。
 1.网飞（Netflix）架构师给出的定义，所谓微服务架构就是服务导向，松耦合有边界的元素构成的架构，松耦合指的是可以独立更新服务，不会对其他服务造成影响。同时，对于数据库需要适当的拆分，有可能会违反规范。
 Cockcroft defines a microservices architecture as a service‑oriented architecture composed of loosely coupled elements that have bounded contexts.
 Loosely coupled means that you can update the services independently; updating one service doesn’t require changing any other services. If you have a bunch of small, specialized services but still have to update them together, they’re not microservices because they’re not loosely coupled. One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it.
 
2.Martin Fowler则认为微服务架构是一种开发一套小服务的方式（与SOA不同），服务间通过一些轻量级的方式通信，如HTTP（这也是为什么REST API近年来这么火）方式。这些围绕业务能力搭建的服务可以独立并且自动化的发布。因为微服务没有一个明确的核心，因此可以用不同的语言和存储技术来开发。
 In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
 
Chris Richardson在他的书（design patterns）中给出了一个较为详细可操作性的关于微服务架构的阐述，通过三个象限的维度拓展应用，即多实例、路由和负载均衡、根据功能拆分，微服务的最小单元——服务，仅仅是一个功能的实现。微服务用大白话来说就是将原先的单体架构拆分成一个个小服务，粒度细化。
 说到微服务，就避不开网飞这家公司，网飞是较早实现微服务架构的公司并且开源了一套完整的组件供其他公司使用，有
 服务发现组件：eureka https://github.com/Netflix/eureka
 负载均衡组件：ribbon https://github.com/Netflix/ribbon
 限流熔断组件：Hystrix https://github.com/Netflix/Hystrix
 路由监控组件：zuul https://github.com/Netflix/zuul
 之后，Pivitol公司在这些组件上做了封装，也开发了一些其他组件组成了一套比较成熟完整的微服务生态
https://github.com/spring-cloud
 
目前市面上做微服务还比较流行的组件有
 Web Service客户端： Spring Cloud Feign https://github.com/spring-cloud/spring-cloud-openfeign
 API网关： Spring Cloud Gateway（目标是取代zuul）
 分布式配置中心： Spring Cloud Config
 阿里巴巴早先的微服务解决方案：Apache Dubbo（https://github.com/apache/dubbo）(该项目已通过Apache孵化，成为阿帕奇基金的顶级项目)
 阿里巴巴微服务一站式解决方案：Spring Cloud Alibaba（https://github.com/spring-cloud-incubator/spring-cloud-alibaba）
 
目前Spring Cloud技术栈的对比如下图，由于Netflex逐渐将组件的开发状态转为维护状态，Pivitol公司可能面临后继乏力的危险，而Spring Cloud Alibaba正在慢慢发力，有可能在未来取代Spring Cloud形成微服务闭环的技术栈。
 
 
 

  
  
 
 
那么微服务架构是什么样的呢？
 在Github上有个叫piggymetrics（https://github.com/sqshq/PiggyMetrics）的项目就很简单明了的展示了何为微服务架构，如下图，作者用Spring Boot， Spring Cloud和Docker等技术栈搭起来一个微服务的演示项目，服务与服务之间通过REST API通信，每个服务拥有独立的数据库
 
 
 

  
  
 
 
下图更加详细的展示了微服务所用到的技术栈和各个微服务组件是如何在整个微服务架构中发挥作用的。
 
 
 

  
  
 
 
ZUUL： API路由
 ELK STACK： 日志分析
 HYSTRIX 和 RIBBON：负载均衡和熔断限流
 EUREKA： 服务发现
 TURBINE： 监控大盘
 Spring Cloud Config: 分布式配置中心
 OAuth2： 服务鉴权授权
 
微服务带来的好处很多，诸如
 使大型复杂应用可以持续性发布和部署（采用DevOps的方式开发，小团队，多次迭代，快速部署，单次部署风险小）
 服务“微”容易维护（代码量较少，容易理解，开发快）
 服务可以独立拓展（可根据应用的特性部署到不同的机器，例如可以将CPU密集型应用和内存密集型应用部署到不同机器，以充分发挥机器性能）
 服务可以单独部署（松耦合，与其他服务的联系不强，自主性强）
 新技术的采用更为方便（例如可以使用Golang写的OAuth2进行鉴权授权，不需要全部使用同一种语言）
 较强的容错性（Hystrix可以防止“雪崩”的产生，可以隔离故障，也可以根据条件进行服务降级， Ribbon实现软负载均衡，减轻单机压力）
 
当然，凡是都有两面性，没有绝对的“银弹”，微服务架构也会带来一些缺点，如
 如何划分服务的边界，根据业务还是根据何种规约
 分布式系统带来的复杂性使得开发、测试和部署都增加难度
 如果发布的特性设计多个服务，需要谨慎和多个团队合作
 采用微服务的时机难以界定
 数据的一致性不好维护
 数据查询难，尤其是涉及到跨数据库
 
对此，Chris Richardson也划分了多个架构模式来应对微服务架构所带来的种种问题，可以说好的架构是演化而来的，例如单体架构演化到微服务架构，可以通过应用设计模式、应用基础设施设计模式和基础设施设计模式多方面来解决微服务带来的问题。其他设计模式会在接下来的文章一一道来，我也会写一些相关的代码示例来更加形象展示微服务的实战，我的github地址：https://github.com/Guilai1990?tab=repositories
 
参考资料：
 
Martin Fowler个人网站 https://www.martinfowler.com/microservices/
 
Adopting Microservices at Netflix: Lessons for Architectural Design
 
PiggyMetrics的Github
 
Chris Richardson —— Microservice Patterns
 
Chris Richardson个人网站 https://microservices.io/patterns/microservices.html

 
 
从软件开发早期（1960 年代）开始，应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性，软件工程师和架构师们做了许多尝试：David Parnas 的模块化和封装 （1972）， Edsger W. Dijkstra （1974）的关注点分离以及 SOA（1988）。
 
他们都是使用分而治之这项成熟的传统技术来应对大型系统的复杂性。自 2010 年开始，这些技术被证实无法继续应对 Web 级应用或者现代大型企业级应用的复杂性。因此架构师和工程师们发展出了一种全新的现代方式来解决这个问题，就是微服务架构。它虽然延续了分而治之的思想，但却是以全新的方式来实现的。
 
软件设计模式是解决软件设计中常见问题的通用、可复用的解决方案。设计模式让我们可以分享通用词汇并使用经实战检验的方案，以免重复造轮子。我先简单介绍下微服务架构。
 
通过阅读这篇文章，你会学到：
 
微服务架构
微服务架构的优势
微服务架构的劣势
何时使用微服务架构
 
最重要的微服务架构设计模式，包括其优缺点、用例、上下文、技术栈示例及可用资源。
 
请注意，本清单中的大部分设计模式常出现在多种语境中，并且可以在非微服务架构中使用。而我将在微服务这个特定语境中介绍它们。
 
1微服务架构
 
我在之前的博客《微服务架构概述及为什么要应用在下个项目》和《单体软件架构真的终结了吗？》中对微服务架构有非常详尽的介绍。如果你感兴趣，可以阅读这两篇博客来深入了解。
 
https://towardsdatascience.com/microservice-architecture-a-brief-overview-and-why-you-should-use-it-in-your-next-project-a17b6e19adfd
 
https://towardsdatascience.com/looking-beyond-the-hype-is-modular-monolithic-software-architecture-really-dead-e386191610f8
 
那到底什么是微服务架构？有很多种定义方法。我的定义是这这样的：
 
微服务架构指的是将大型复杂系统按功能或者业务需求垂直切分成更小的子系统，这些子系统以独立部署的子进程存在，它们之间通过轻量级的、跨语言的同步（比如 REST，gRPC）或者异步（消息）网络调用进行通信。
 
下面是基于微服务架构的商业 Web 应用的组件视图：
 


 
来自 Md Kamaruzzaman 的微服务架构
 
 微服务架构的重要特征
 
整个应用程序被拆分成相互独立但包含多个内部模块的子进程
与模块化的单体应用（Modular Monoliths）或 SOA 相反，微服务应用程序根据业务范围或领域垂直拆分。
微服务边界是外部的，微服务之间通过网络调用（RPC 或消息）相互通信。
微服务是独立的进程，它们可以独立部署。
它们以轻量级的方式进行通信，不需要任何智能通信通道。
 
 微服务架构的优点
 
更好的开发规模
更快的开发速度
支持迭代开发或现代化增量开发
充分利用现代软件开发生态系统的优势（云、容器、 DevOps、Serverless）
支持水平缩放和细粒度缩放
小体量，较低了开发人员的认知复杂性
 
 微服务架构的缺点
 
更高数量级的活动组件（服务、数据库、进程、容器、框架）
复杂性从代码转移到基础设施
RPC 调用和网络通信的大量增加
整个系统的安全性管理更具有挑战性
整个系统的设计变得更加困难
引入了分布式系统的复杂性
 
 何时使用微服务架构
 
大规模 Web 应用开发
跨团队企业级应用协作开发
长期收益优先于短期收益
团队拥有能够设计微服务架构的软件架构师或高级工程师
 
2微服务架构的设计模式
 
 独享数据库（Database per Microservice）
 
当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。
 
更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。
 


 
Md Kamaruzzaman 的微服务独享数据库
 
优点
 
数据由服务完全所有
服务的开发团队之间耦合度降低
 
缺点
 
服务间的数据共享变得更有挑战性
在应用范围的保证 ACID 事务变得困难许多
细心设计如何拆分单体数据库是一项极具挑战的任务
 
何时使用独享数据库
 
在大型企业应用程序中
当团队需要完全把控微服务以实现开发规模扩展和速度提升
 
何时不宜使用独享数据库
 
在小规模应用中
如果是单个团队开发所有微服务
 
可用技术示例
 
所有 SQL、 NoSQL 数据库都提供数据的逻辑分离（例如，单独的表、集合、结构、数据库）。
 
 事件源（Event Sourcing）
 
在微服务架构中，特别使用独享数据库时，微服务之间需要进行数据交换。对于弹性高可伸缩的和可容错的系统，它们应该通过交换事件进行异步通信。在这种情况，您可能希望进行类似更新数据库并发送消息这样的原子操作，如果在大数据量的分布式场景使用关系数据库，您将无法使用两阶段锁协议（2PL），因为它无法伸缩。而 NoSQL 数据库因为大多不支持两阶段锁协议甚至无法实现分布式事务。
 
在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务实体的当前“状态”，而在事件源中任何“状态”更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。这意味着业务实体的所有更改将被保存为一系列不可变的事件。因为数据是作为一系列事件存储的，而非直接更新存储，所以各项服务可以通过重放事件存储中的事件来计算出所需的数据状态。
 


 
Md Kamaruzzaman 的事件源
 
优点
 
为高可伸缩系统提供原子性操作
自动记录实体变更历史，包括时序回溯功能
松耦合和事件驱动的微服务
 
缺点
 
从事件存储中读取实体成为新的挑战，通常需要额外的数据存储（CQRS 模式）。
系统整体复杂性增加了，通常需要领域驱动设计。
系统需要处理事件重复（幂等）或丢失
变更事件结构成为新的挑战。
 
何时使用事件源
 
使用关系数据库的、高可伸缩的事务型系统
使用 NoSQL 数据库的事务型系统
弹性高可伸缩微服务架构
典型的消息驱动或事件驱动系统（电子商务、预订和预约系统）
 
何时不宜使用事件源
 
使用 SQL 数据库的低可伸缩性事务型系统
在服务可以同步交换数据（例如，通过 API）的简单微服务架构中。
 
可用技术示例
 
事件存储：EventStoreDB、Apache Kafka、Confluent Cloud、AWS Kinesis、Azure Event Hub、GCP Pub/Sub、Azure Cosmos DB、MongoDB、Cassandra、Amazon DynamoDB
 
框架：Lagom、Akka、Spring、akkatecture、Axon、Eventuate
 
 命令和查询职责分离（CQRS）
 
如果我们使用事件源，那么从事件存储中读取数据就变得困难了。要从数据存储中获取实体，我们需要处理所有的实体事件。有时我们对读写操作还会有不同的一致性和吞吐量要求。
 
这种情况，我们可以使用 CQRS 模式。在该模式中，系统的数据修改部分（命令）与数据读取部分（查询）是分离的。而 CQRS 模式有两种容易令人混淆的模式，分别是简单的和高级的。
 
在其简单形式中，不同实体或 ORM 模型被用于读写操作，如下所示：
 

 
Md Kamaruzzaman 的 CQRS （简单）
 
它有助于强化单一职责原则和分离关注点，从而实现更简洁的设计。
 
在其高级形式中，会有不同的数据存储用于读写操作。高级的 CQRS 通常结合事件源模式。根据不同情况，会使用不同类型的写数据存储和读数据存储。写数据存储是“记录的系统”，也就是整个系统的核心源头。
 


 
Md Kamaruzzaman 的 CQRS（高级）
 
对于读频繁的应用程序或微服务架构，OLTP 数据库（任何提供 ACID 事务保证的关系或非关系数据库）或分布式消息系统都可以被用作写存储。对于写频繁的应用程序（写操作高可伸缩性和大吞吐量），需要使用写可水平伸缩的数据库（如全球托管的公共云数据库）。标准化的数据则保存在写数据存储中。
 
对搜索（例如 Apache Solr、Elasticsearch）或读操作（KV 数据库、文档数据库）进行优化的非关系数据库常被用作读存储。许多情况会在需要 SQL 查询的地方使用读可伸缩的关系数据库。非标准化和特殊优化过的数据则保存在读存储中。
 
数据是从写存储异步复制到读存储中的，所以读存储和写存储之间会有延迟，但最终是一致的。
 
优点
 
在事件驱动的微服务中数据读取速度更快
数据的高可用性
读写系统可独立扩展
 
缺点
 
读数据存储是弱一致性的（最终一致性）
整个系统的复杂性增加了，混乱的 CQRS 会显着危害整个项目。
 
何时使用 CQRS
 
在高可扩展的微服务架构中使用事件源
在复杂领域模型中，读操作需要同时查询多个数据存储。
在读写操作负载差异明显的系统中
 
何时不宜使用 CQRS
 
在没有必要存储大量事件的微服务架构中，用事件存储快照来计算实体状态是一个更好的选择。
在读写操作负载相近的系统中。
 
可用技术示例
 
写存储：EventStoreDB， Apache Kafka， Confluent Cloud， AWS Kinesis， Azure Event Hub， GCP Pub/Sub， Azure Cosmos DB， MongoDB， Cassandra. Amazon DynamoDB
 
读存储：Elastic Search， Solr， Cloud Spanner， Amazon Aurora， Azure Cosmos DB， Neo4j
 
框架：Lagom， Akka， Spring， akkatecture， Axon， Eventuate
 
 Saga
 
如果微服务使用独享数据库，那么通过分布式事务管理一致性是一个巨大的挑战。你无法使用传统的两阶段提交协议，因为它要么不可伸缩（关系数据库），要么不被支持（多数非关系数据库）。
 
但您还是可以在微服务架构中使用 Saga 模式实现分布式事务。Saga 是 1987 年开发的一种古老模式，是关系数据库中关于大事务的一个替代概念。但这种模式的一种现代变种对分布式事务也非常有效。Saga 模式是一个本地事务序列，其每个事务在一个单独的微服务内更新数据存储并发布一个事件或消息。Saga 中的首个事务是由外部请求（事件或动作）初始化的，一旦本地事务完成（数据已保存在数据存储且消息或事件已发布），那么发布的消息或事件则会触发 Saga 中的下一个本地事务。
 


 
Md Kamaruzzaman 的 Saga
 
如果本地事务失败，Saga 将执行一系列补偿事务来回滚前面本地事务的更改。
 
Saga 事务协调管理主要有两种形式：
 
事件编排 Choreography：分散协调，每个微服务生产并监听其他微服务的事件或消息然后决定是否执行某个动作。
命令编排 Orchestration：集中协调，由一个协调器告诉参与的微服务哪个本地事务需要执行。
 
优点
 
为高可伸缩或松耦合的、事件驱动的微服务架构提供一致性事务。
为使用了不支持 2PC 的非关系数据库的微服务架构提供一致性事务。
 
缺点
 
需要处理瞬时故障，并且提供等幂性。
难以调试，而且复杂性随着微服务数量增加而增加。
 
何时使用 Saga
 
在使用了事件源的高可伸缩、松耦合的微服务中。
在使用了分布式非关系数据库的系统中。
 
何时不宜使用 Saga
 
使用关系数据库的低可伸缩性事务型系统。
在服务间存在循环依赖的系统中。
 
可用技术示例
 
Axon， Eventuate， Narayana
 
 面向前端的后端 （BFF）
 
在现代商业应用开发，特别是微服务架构中，前后端应用是分离和独立的服务，它们通过 API 或 GraphQL 连接。如果应用程序还有移动 App 客户端，那么 Web 端和移动客户端使用相同的后端微服务就会出现问题。因为移动客户端和 Web 客户端有不同的屏幕尺寸、显示屏、性能、能耗和网络带宽，它们的 API 需求不同。
 
面向前端的后端模式适用于需要为特殊 UI 定制单独后端的场景。它还提供了其他优势，比如作为下游微服务的封装，从而减少 UI 和下游微服务之间的频繁通信。此外，在高安全要求的场景中，BFF 为部署在 DMZ 网络中的下游微服务提供了更高的安全性。
 


 
Md Kamaruzzaman 的面向前端的后端
 
优点
 
分离 BFF 之间的关注点，使得我们可以为具体的 UI 优化他们。
提供更高的安全性
减少 UI 和下游微服务之间频繁的通信
 
缺点
 
BFF 之间代码重复
大量的 BFF 用于其他用户界面（例如，智能电视，Web，移动端，PC 桌面版）
需要仔细的设计和实现，BFF 不应该包含任何业务逻辑，而应只包含特定客户端逻辑和行为。
 
何时使用 BFF
 
如果应用程序有多个含不同 API 需求的 UI
出于安全需要，UI 和下游微服务之间需要额外的层。
如果在 UI 开发中使用微前端。
 
何时不宜使用 BFF
 
如果应用程序虽有多个 UI，但使用的 API 相同。
如果核心微服务不是部署在 DMZ 网络中。
 
可用技术示例
 
任何后端框架（Node.js，Spring，Django，Laravel，Flask，Play，…）都能支持。
 
 API 网关
 
在微服务架构中，UI 通常连接多个微服务。如果微服务是细粒度的（FaaS） ，那么客户端可能需要连接非常多的微服务，这将变得繁杂和具有挑战性。此外，这些服务包括它们的 API 还将不断进化。大型企业还希望能有其他横切关注点（SSL 终止、身份验证、授权、节流、日志记录等）。
 
一个解决这些问题的可行方法是使用 API 网关。API 网关位于客户端 APP 和后端微服务之间充当 facade，它可以是反向代理，将客户端请求路由到适当的后端微服务。它还支持将客户端请求扇出到多个微服务，然后将响应聚合后返回给客户端。它还支持必要的横切关注点。
 


 
Md Kamaruzzaman 的 API 网关
 
优点
 
在前端和后端服务之间提供松耦合
减少客户端和微服务之间的调用次数
通过 SSL 终端、身份验证和授权实现高安全性
集中管理的横切关注点，例如，日志记录和监视、节流、负载平衡。
 
缺点
 
可能导致微服务架构中的单点故障
额外的网络调用带来的延迟增加
如果不进行扩展，它们很容易成为整个企业应用的瓶颈。
额外的维护和开发费用
 
何时使用 API 网关
 
在复杂的微服务架构中，它几乎是必须的。
在大型企业中，API 网关是中心化安全性和横切关注点的必要工具。
 
何时不宜使用 API 网关
 
在安全和集中管理不是最优先要素的私人项目或小公司中。
如果微服务的数量相当少。
 
可用技术示例
 
Amazon API 网关， Azure API 管理， Apigee， Kong， WSO2 API 管理器
 
 Strangler
 
如果想在运行中的项目中使用微服务架构，我们需要将遗留的或现有的单体应用迁移到微服务。将现有的大型在线单体应用程序迁移到微服务是相当有挑战性的，因为这可能破坏应用程序的可用性。
 
一个解决方案是使用 Strangler 模式。Strangler 模式意味着通过使用新的微服务逐步替换特定功能，将单体应用程序增量地迁移到微服务架构。此外，新功能只在微服务中添加，而不再添加到遗留的单体应用中。然后配置一个 Facade （API 网关）来路由遗留单体应用和微服务间的请求。当某个功能从单体应用迁移到微服务，Facade 就会拦截客户端请求并路由到新的微服务。一旦迁移了所有的功能，遗留单体应用程序就会被“扼杀（Strangler）”，即退役。
 


 
Md Kamaruzzaman 的 Strangler
 
优点
 
安全的迁移单体应用程序到微服务
可以并行地迁移已有功能和开发新功能
迁移过程可以更好把控节奏
 
缺点
 
在现有的单体应用服务和新的微服务之间共享数据存储变得具有挑战性
添加 Facade （API 网关）将增加系统延迟
端到端测试变得困难
 
何时使用 Strangler
 
将大型后端单体应用程序的增量迁移到微服务
 
何时不宜使用 Strangler
 
如果后端单体应用很小，那么全量替换会更好。
如果无法拦截客户端对遗留的单体应用程序的请求。
 
可用技术示例
 
API 网关后端应用框架。
 
 断路器
 
在微服务架构中，微服务通过同步调用其他服务来满足业务需求。服务调用会由于瞬时故障（网络连接缓慢、超时或暂时不可用） 导致失败，这种情况重试可以解决问题。然而，如果出现了严重问题（微服务完全失败），那么微服务将长时间不可用，这时重试没有意义且浪费宝贵的资源（线程被阻塞，CPU 周期被浪费）。此外，一个服务的故障还会引发整个应用系统的级联故障。这时快速失败是一种更好的方法。
 
在这种情况，可以使用断路器模式挽救。一个微服务通过代理请求另一个微服务，其工作原理类似于电气断路器，代理通过统计最近发生的故障数量，并使用它来决定是继续请求还是简单的直接返回异常。
 


 
Md Kamaruzzaman 的断路器
 
断路器可以有以下三种状态：
 
关闭：断路器将请求路由到微服务，并统计给定时段内的故障数量，如果超过阈值，它就会触发并进入打开状态。
打开：来自微服务的请求会快速失败并返回异常。在超时后，断路器进入半开启状态。
半开：只有有限数量的微服务请求被允许通过并进行调用。如果这些请求成功，断路器将进入闭合状态。如果任何请求失败，断路器则会进入开启状态。
 
优点
 
提高微服务架构的容错性和弹性
阻止引发其他微服务的级联故障
 
缺点
 
需要复杂的异常处理
日志和监控
应该支持人工复位
 
何时使用断路器
 
在微服务间使用同步通信的紧耦合的微服务架构中
如果微服务依赖多个其他微服务
 
何时不宜使用断路器
 
松耦合、事件驱动的微服务架构
如果微服务不依赖于其他微服务
 
可用技术示例
 
API 网关，服务网格，各种断路器库（Hystrix， Reselience4J， Polly）。
 
 外部化配置
 
每个业务应用都有许多用于各种基础设施的配置参数（例如，数据库、网络、连接的服务地址、凭据、证书路径）。此外在企业应用程序通常部署在各种运行环境（Local、 Dev、 Prod）中，实现这些的一个方法是通过内部配置。这是一个致命糟糕实践，它会导致严重的安全风险，因为生产凭证很容易遭到破坏。此外，配置参数的任何更改都需要重新构建应用程序，这在在微服务架构中会更加严峻，因为我们可能拥有数百个服务。
 
更好的方法是将所有配置外部化，使得构建过程与运行环境分离，生产的配置文件只在运行时或通过环境变量使用，从而最小化了安全风险。
 
优点
 
生产配置不属于代码库，因而最小化了安全漏洞。
修改配置参数不需要重新构建应用程序。
 
缺点
 
我们需要选择一个支持外部化配置的框架。
 
何时使用外部化配置
 
任何重要的生产应用程序都必须使用外部化配置。
 
何时不宜使用外部化配置
 
在验证概念的开发中。
 
可用技术示例
 
几乎所有企业级的现代框架都支持外部化配置。
 
 消费端驱动的契约测试
 
在微服务架构中，通常有许多有不同团队开发的微服务。这些微型服务协同工作来满足业务需求（例如，客户请求），并相互进行同步或异步通信。消费端微服务的集成测试具有挑战性，通常用 TestDouble 以获得更快、更低成本的测试运行。但是 TestDouble 通常并不能代表真正的微服务提供者，而且如果微服务提供者更改了它的 API 或 消息，那么 TestDouble 将无法确认这些。另一种选择是进行端到端测试，尽管它在生产之前是强制性的，但却是脆弱的、缓慢的、昂贵的且不能替代集成测试（Test Pyramid）。
 
在这方面消费端驱动的契约测试可以帮助我们。在这里，负责消费端微服务的团队针对特定的服务端微服务，编写一套包含了其请求和预期响应（同步）或消息（异步）的测试套件，这些测试套件称为显式的约定。对于微服务服务端，将其消费端所有约定的测试套件都添加到其自动化测试中。当特定服务端微服务的自动化测试执行时，它将一起运行自己的测试和约定的测试并进行验证。通过这种方式，契约测试可以自动的帮助维护微服务通信的完整性。
 
优点
 
如果提供程序意外更改 API 或消息，可以被快速的自动发现。
更少意外、更健壮，特别是包含大量微服务的企业应用程序。
改善团队自主性。
 
缺点
 
需要额外的工作来开发和集成微服务服务端的契约测试，因为他们可能使用完全不同的测试工具。
如果契约测试与真实服务情况不匹配，将可能导致生产故障。
 
何时使用需求驱动的契约测试
 
在大型企业业务应用程序中，通常由不同的团队开发不同服务。
 
何时不宜使用消费端驱动的契约测试
 
所有微服务由同一团队负责开发的小型简单的应用程序。
如果服务端微服务是相对稳定的，并且不处在活跃的开发状态。
 
可用技术示例
 
Pact， Postman， Spring Cloud Contract
 
3总结
 
在现代大规模企业软件开发中，微服务架构能够帮助开发扩展规模并带来很多长期收益。但是微服务架构并不是随处可用的银弹，如果应用在错误的应用程序类型，微服务架构将弊大于利。希望采用微服务架构的开发团队应该遵循最佳实践，并使用一系列可重用的、久经锤炼的设计模式。
 
微服务架构中至关重要的设计模式是独享数据库。实现这种设计模式具有挑战性，需要其他几种密切相关的设计模式（事件驱动、 CQRS、 Saga）来支持。在具有多个客户端（Web、 Mobile、 Desktop、 Smart Devices）的典型业务应用程序中，客户端和微服务之间的通信量可能是很大的，并且需要统一的安全控制，在这种情况面向前端的后端和 API 网关的设计非常有用。此外，断路器模式可以大大地帮助应对这类应用程序的错误处理场景。迁移遗留的单体应用到微服务是极具挑战性的，而 Strangler 模式可以帮助做到这点。消费端驱动的契约测试是微服务集成测试的基础模式。另外外部化配置是任何现代化应用程序开发中的一种必备模式。
 
这个系列并不全面，在实际情况中您可能需要其他的设计模式，但这个系列能为您提供一个关于微服务架构设计模式的极好介绍。
 
原文链接：
 
https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
 

 
你还没有注册，无法下载本站所有资源，请立即注册！
 
您需要 登录 才可以下载或查看，没有帐号？立即注册
 
x
 
java自学网(http://www.137zw.com)-java论坛，java电子书推荐：《 微服务架构设计模式》
 
java电子书推荐理由：本书由微服务架构的先驱、Java开发者社区的意见领袖 Chris Richardson亲笔撰写，旨在帮助架构师和程序员学会使用微服务架构成功开发应用程序。书中描述了如何解决我们将面临的众多架构设计挑战，包括如何管理分布式数据，还介绍了如何将单体应用程序重构为微服务架构，涵盖44个架构设计模式，系统解决服务拆分、事务管理、查询和跨服务通信等难题。本书并不是鼓吹微服务架构的宣言，作者既介绍了微服务的原理、原则，又详细讲解了实际落地中的架构设计模式，将使你理解微服务架构、它的好处和弊端，以及应该何时使用微服务架构。本书将帮助你建立微服务的全局视野，并学会在纷繁复杂的情况下做出正确的架构选择和取舍。
 
作者：克里斯理查森 Chris Richardson
 
出版社：机械工业出版社
 
出版时间：2019-05-10
 
书籍价格：139.00元java电子书目录：
 
目　　录
 
写给中文版读者的话
 
译者序
 
中文版序一
 
中文版序二
 
前言
 
引言
 
第1章　逃离单体地狱   / 1
 
1.1　迈向单体地狱的漫长旅程   / 2
 
1.1.1　FTGO应用程序的架构   / 3
 
1.1.2　单体架构的好处   / 4
 
1.1.3　什么是单体地狱   / 4
 
1.2　为什么本书与你有关   / 7
 
1.3　你会在本书中学到什么   / 8
 
1.4　拯救之道：微服务架构   / 8
 
1.4.1　扩展立方体和服务   / 9
 
1.4.2　微服务架构作为模块化的一种形式   / 11
 
1.4.3　每个服务都拥有自己的数据库   / 12
 
1.4.4　FTGO的微服务架构   / 12
 
1.4.5　微服务架构与SOA的异同  / 14
 
1.5　微服务架构的好处和弊端   / 15
 
1.5.1　微服务架构的好处   / 15
 
1.5.2　微服务架构的弊端   / 17
 
1.6　微服务架构的模式语言   / 19
 
1.6.1　微服务架构并不是“银弹”   / 20
 
1.6.2　模式和模式语言   / 21
 
1.6.3　微服务架构的模式语言概述   / 24
 
1.7　微服务之上：流程和组织   / 29
 
1.7.1　进行软件开发和交付的组织   / 30
 
1.7.2　进行软件开发和交付的流程   / 31
 
1.7.3　采用微服务架构时的人为因素   / 32
 
第2章　服务的拆分策略   / 34
 
2.1　微服务架构到底是什么   / 35
 
2.1.1　软件架构是什么，为什么它如此重要   / 35
 
2.1.2　什么是架构的风格   / 37
 
2.1.3　微服务架构是一种架构风格   / 40
 
2.2　为应用程序定义微服务架构   / 43
 
2.2.1　识别系统操作   / 45
 
2.2.2　根据业务能力进行服务拆分   / 50
 
2.2.3　根据子域进行服务拆分   / 53
 
2.2.4　拆分的指导原则   / 54
 
2.2.5　拆分单体应用为服务的难点   / 56
 
2.2.6　定义服务API   / 59
 
第3章　微服务架构中的进程间通信   / 63
 
3.1　微服务架构中的进程间通信概述   / 64
 
3.1.1　交互方式   / 64
 
3.1.2　在微服务架构中定义API   / 66
 
3.1.3　API的演化   / 67
 
3.1.4　消息的格式   / 69
 
3.2　基于同步远程过程调用模式的通信   / 70
 
3.2.1　使用REST   / 71
 
3.2.2　使用gRPC   / 74
 
3.2.3　使用断路器模式处理局部故障   / 75
 
3.2.4　使用服务发现   / 78
 
3.3　基于异步消息模式的通信   / 82
 
3.3.1　什么是消息传递   / 83
 
3.3.2　使用消息机制实现交互方式   / 84
 
3.3.3　为基于消息机制的服务API创建API规范   / 86
 
3.3.4　使用消息代理   / 87
 
3.3.5　处理并发和消息顺序   / 91
 
3.3.6　处理重复消息   / 92
 
3.3.7　事务性消息   / 93
 
3.3.8　消息相关的类库和框架   / 97
 
3.4　使用异步消息提高可用性   / 99
 
3.4.1　同步消息会降低可用性   / 99
 
3.4.2　消除同步交互   / 101
 
第4章　使用Saga管理事务　   / 106
 
4.1　微服务架构下的事务管理   / 107
 
4.1.1　微服务架构对分布式事务的需求   / 108
 
4.1.2　分布式事务的挑战   / 109
 
4.1.3　使用Saga模式维护数据一致性   / 109
 
4.2　Saga的协调模式   / 113
 
4.2.1　协同式Saga   / 113
 
4.2.2　编排式Saga   / 117
 
4.3　解决隔离问题   / 121
 
4.3.1　缺乏隔离导致的问题   / 122
 
4.3.2　Saga模式下实现隔离的对策   / 123
 
4.4　Order Service和Create Order Saga的设计  / 127
 
4.4.1　OrderService类  / 128
 
4.4.2　Create Order Saga的实现  / 129
 
4.4.3　OrderCommandHandlers类  / 136
 
4.4.4　OrderServiceConfiguration类   / 138
 
第5章　微服务架构中的业务逻辑设计   / 141
 
5.1　业务逻辑组织模式   / 142
 
5.1.1　使用事务脚本模式设计业务逻辑   / 143
 
5.1.2　使用领域模型模式设计业务逻辑   / 144
 
5.1.3　关于领域驱动设计   / 146
 
5.2　使用聚合模式设计领域模型   / 146
 
5.2.1　模糊边界所带来的问题   / 147
 
5.2.2　聚合拥有明确的边界   / 149
 
5.2.3　聚合的规则   / 150
 
5.2.4　聚合的颗粒度   / 152
 
5.2.5　使用聚合设计业务逻辑   / 153
 
5.3　发布领域事件   / 154
 
5.3.1　为什么需要发布变更事件   / 154
 
5.3.2　什么是领域事件   / 155
 
5.3.3　事件增强   / 155
 
5.3.4　识别领域事件   / 156
 
5.3.5　生成和发布领域事件   / 157
 
5.3.6　消费领域事件   / 161
 
5.4　Kitchen Service的业务逻辑   / 162
 
5.5　Order Service的业务逻辑   / 167
 
5.5.1　Order聚合   / 169
 
5.5.2　OrderService类  / 173
 
第6章　使用事件溯源开发业务逻辑   / 176
 
6.1　使用事件溯源开发业务逻辑概述   / 177
 
6.1.1　传统持久化技术的问题   / 177
 
6.1.2　什么是事件溯源   / 179
 
6.1.3　使用乐观锁处理并发更新   / 186
 
6.1.4　事件溯源和发布事件   / 186
 
6.1.5　使用快照提升性能   / 188
 
6.1.6　幂等方式的消息处理   / 189
 
6.1.7　领域事件的演化   / 190
 
6.1.8　事件溯源的好处   / 192
 
6.1.9　事件溯源的弊端   / 193
 
6.2　实现事件存储库   / 194
 
6.2.1　Eventuate Local事件存储库的工作原理   / 195
 
6.2.2　Eventuate的Java客户端框架   / 198
 
6.3　同时使用Saga和事件溯源   / 201
 
6.3.1　使用事件溯源实现协同式Saga   / 203
 
6.3.2　创建编排式Saga   / 203
 
6.3.3　实现基于事件溯源的Saga参与方  / 205
 
6.3.4　实现基于事件溯源的Saga编排器  / 208
 
第7章　在微服务架构中实现查询   / 212
 
7.1　使用API组合模式进行查询   / 213
 
7.1.1　findOrder()查询操作   / 213
 
7.1.2　什么是API组合模式   / 214
 
7.1.3　使用API组合模式实现findOrder()查询操作   / 215
 
7.1.4　API组合模式的设计缺陷   / 216
 
7.1.5　API组合模式的好处和弊端   / 219
 
7.2　使用CQRS模式  / 220
 
7.2.1　为什么要使用CQRS   / 220
 
7.2.2　什么是CQRS   / 223
 
7.2.3　CQRS的好处   / 226
 
7.2.4　CQRS的弊端   / 227
 
7.3　设计CQRS视图  / 228
 
7.3.1　选择视图存储库   / 229
 
7.3.2　设计数据访问模块   / 230
 
7.3.3　添加和更新CQRS视图  / 232
 
7.4　实现基于AWS DynamoDB的CQRS视图   / 233
 
7.4.1　OrderHistoryEventHandlers模块  / 234
 
7.4.2　DynamoDB中的数据建模和查询设计   / 235
 
7.4.3　OrderHistoryDaoDynamoDb类  / 239
 
第8章　外部API模式  / 244
 
8.1　外部API的设计难题   / 245
 
8.1.1　FTGO移动客户端API的设计难题   / 246
 
8.1.2　其他类型客户端API的设计难题   / 248
 
8.2　API Gateway模式  / 250
 
8.2.1　什么是API Gateway模式  / 250
 
8.2.2　API Gateway模式的好处和弊端   / 256
 
8.2.3　以Netflix为例的API Gateway   / 257
 
8.2.4　API Gateway的设计难题   / 258
 
8.3　实现一个API Gateway   / 260
 
8.3.1　使用现成的API Gateway产品或服务   / 261
 
8.3.2　开发自己的API Gateway   / 262
 
8.3.3　使用GraphQL实现API Gateway   / 269
 
第9章　微服务架构中的测试策略(上)   / 282
 
9.1　微服务架构中的测试策略概述   / 284
 
9.1.1　什么是测试   / 284
 
9.1.2　微服务架构中的测试挑战   / 289
 
9.1.3　部署流水线   / 295
 
9.2　为服务编写单元测试   / 296
 
9.2.1　为实体编写单元测试   / 298
 
9.2.2　为值对象编写单元测试   / 299
 
9.2.3　为Saga编写单元测试   / 300
 
9.2.4　为领域服务编写单元测试   / 302
 
9.2.5　为控制器编写单元测试   / 303
 
9.2.6　为事件和消息处理程序编写单元测试   / 305
 
第10章　微服务架构中的测试策略(下)   / 308
 
10.1　编写集成测试   / 308
 
10.1.1　针对持久化层的集成测试   / 311
 
10.1.2　针对基于REST的请求/响应式交互的集成测试   / 312
 
10.1.3　针对发布/订阅式交互的集成测试   / 316
 
10.1.4　针对异步请求/响应式交互的集成契约测试   / 320
 
10.2　编写组件测试   / 324
 
10.2.1　定义验收测试   / 325
 
10.2.2　使用Gherkin编写验收测试   / 326
 
10.2.3　设计组件测试   / 328
 
10.2.4　为FTGO的Order Service编写组件测试   / 330
 
10.3　端到端测试   / 334
 
10.3.1　设计端到端测试   / 335
 
10.3.2　编写端到端测试   / 335
 
10.3.3　运行端到端测试   / 336
 
第11章　开发面向生产环境的微服务应用   / 338
 
11.1　开发安全的服务   / 339
 
11.1.1　传统单体应用程序的安全性   / 340
 
11.1.2　在微服务架构中实现安全性   / 343
 
11.2　设计可配置的服务   / 349
 
11.2.1　使用基于推送的外部化配置   / 350
 
11.2.2　使用基于拉取的外部化配置   / 352
 
11.3　设计可观测的服务   / 353
 
11.3.1　使用健康检查API模式  / 355
 
11.3.2　使用日志聚合模式   / 357
 
11.3.3　使用分布式追踪模式   / 358
 
11.3.4　使用应用程序指标模式   / 361
 
11.3.5　使用异常追踪模式   / 364
 
11.3.6　使用审计日志模式   / 365
 
11.4　使用微服务基底模式开发服务   / 367
 
11.4.1　使用微服务基底   / 368
 
11.4.2　从微服务基底到服务网格   / 368
 
第12章　部署微服务应用   / 371
 
12.1　部署模式：编程语言特定的发布包格式   / 374
 
12.1.1　使用编程语言特定的发布包格式进行部署的好处   / 376
 
12.1.2　使用编程语言特定的发布包格式进行部署的弊端   / 377
 
12.2　部署模式：将服务部署为虚拟机   / 378
 
12.2.1　将服务部署为虚拟机的好处   / 380
 
12.2.2　将服务部署为虚拟机的弊端   / 380
 
12.3　部署模式：将服务部署为容器   / 381
 
12.3.1　使用Docker部署服务   / 383
 
12.3.2　将服务部署为容器的好处   / 385
 
12.3.3　将服务部署为容器的弊端   / 386
 
12.4　使用Kubernetes部署FTGO应用程序   / 386
 
12.4.1　什么是Kubernetes   / 386
 
12.4.2　在Kubernetes上部署Restaurant Service   / 389
 
12.4.3　部署API Gateway   / 392
 
12.4.4　零停机部署   / 393
 
12.4.5　使用服务网格分隔部署与发布流程   / 394
 
12.5　部署模式：Serverless部署  / 402
 
12.5.1　使用AWS Lambda进行Serverless部署  / 403
 
12.5.2　开发Lambda函数  / 404
 
12.5.3　调用Lambda函数  / 404
 
12.5.4　使用Lambda函数的好处   / 405
 
12.5.5　使用Lambda函数的弊端   / 406
 
12.6　使用AWS Lambda和AWS Gateway部署RESTful服务  / 406
 
12.6.1　AWS Lambda版本的Restaurant Service   / 407
 
12.6.2　把服务打包为ZIP文件  / 411
 
12.6.3　使用Serverless框架部署Lambda函数  / 412
 
第13章　微服务架构的重构策略   / 415
 
13.1　重构到微服务需要考虑的问题   / 416
 
13.1.1　为什么要重构单体应用   / 416
 
13.1.2　绞杀单体应用   / 417
 
13.2　将单体应用重构为微服务架构的若干策略   / 420
 
13.2.1　将新功能实现为服务   / 420
 
13.2.2　隔离表现层与后端   / 422
 
13.2.3　提取业务能力到服务中   / 423
 
13.3　设计服务与单体的协作方式   / 429
 
13.3.1　设计集成胶水 javazx.com   / 430
 
13.3.2　在服务和单体之间维持数据一致性   / 434
 
13.3.3　处理身份验证和访问授权   / 438
 
13.4　将新功能实现为服务：处理错误配送订单   / 440
 
13.4.1　Delayed Delivery Service的设计  / 441
 
13.4.2　为Delayed Delivery Service设计集成胶水   / 442
 
13.5　从单体中提取送餐管理功能   / 444
 
13.5.1　现有的送餐管理功能   / 444
 
13.5.2　Delivery Service概览  / 446
 
13.5.3　设计Delivery Service的领域模型   / 447
 
13.5.4　Delivery Service集成胶水的设计   / 450
 
13.5.5　修改FTGO单体使其能够与Delivery Service交互  / 451
 
Java资料百度网盘下载地址链接(百度云)：目前只有英文版本，中文版本全部挂了，微服务架构设计模式  PDF 高清 电子书 百度云.ra【密码回帖可见】
 
游客，如果您要查看本帖隐藏内容请回复[/hide]

链接：https://pan.baidu.com/s/1RCsi9bDoPgQw0swztzsmBQ 
 提取码：jhie
 
若链接失效，请联系本人：18642984053@163.com