微服务中的设计模式

          说到设计模式，大家一般会想到，工厂、单例等24种基本设计模式，当然也会想到并发型模式，生产-消费者模式，线程池模式等，但是微服务中用到什么设计模式了？前两篇介绍了，挎斗模式和代表模式，当然这一类设计模式属于云设计模式。azurecat模式和实践团队在azure架构中心发布了九种新的设计模式。在设计和实现微服务时，这九种模式特别有用。微服务越来越变的流行是记录这些模式的动机。

下图说明了如何在微服务架构中使用这些模式：

对于每种模式，我们都会描述问题，解决方案，何时使用模式以及实现注意事项。

• ambassador(代表模式) 可用于以一种与语言无关的方式卸载常见客户端连接任务，如监视、记录、路由、安全（如 tls）。
• anti-corruption layer (防损层模式) 实现了新旧应用程序之间的外观，以确保新应用程序的设计不受遗留系统依赖性的限制。使用此模式可确保应用程序的设计不受限于对外部子系统的依赖。 此模式最先由 eric evans 在 domain-driven design（域驱动的设计）中描述。
• backends for frontends (用于前端的后端模式) 创建单独的后端服务，供特定的前端应用程序或接口使用。 要避免为多个接口自定义一个后端时，此模式十分有用。后端为不同类型的客户端（如桌面和移动设备）创建单独的后端服务。这样，单个后端服务不需要处理各种客户端类型的冲突要求。通过分离客户特定的问题，这种模式可以帮助保持每个微服务的简单性。
• bulkhead（隔舱模式）之所以称为“隔舱”(bulkhead)，是因为它类似于船体的分段区。 如果船体受到破坏，只有受损的分段才会进水，从而可以防止船只下沉。为每个工作负载或服务隔离关键资源，例如连接池，内存和cpu。通过使用隔板，单个工作负载（或服务）无法消耗所有资源，使其他资源匮乏。此模式通过防止由一个服务引起的级联故障来提高系统的弹性。
• gateway aggregation（网关聚合模式）使用网关可将多个单独请求聚合成一个请求。 当客户端必须向不同的后端系统发出多个调用来执行某项操作时，此模式非常有用使用网关可将多个单独请求聚合成一个请求。 当客户端必须向不同的后端系统发出多个调用来执行某项操作时，此模式非常有用。
• gateway offloading（网关卸载方式）将共享或专用服务功能卸载到网关代理。 此模式可以通过将共享服务功能（如 ssl 证书的使用）从应用程序的其他部分移动到网关，简化应用程序开发。
• gateway routing（网关路由模式）使用单个终结点将请求路由到多个服务。 如果希望在单个终结点上公开多个服务，并根据请求路由到适当的服务，则此模式非常有用。
• sidecar（挎斗模式 ）将应用程序的帮助程序组件部署为单独的容器或进程，以提供隔离和封装。使用此模式还可以使用异构组件和技术来构建应用程序。
• strangler（绞杀者模式）通过将特定的功能片断逐渐取代为新的应用程序和服务，逐步迁移旧系统。 随着旧系统的功能被替换，新系统最终将取代旧系统的所有功能，抑制旧系统并使其停用。通过逐步用新服务替换特定功能来支持增量迁移。

              微服务的目标是通过将应用程序分解为可以独立部署的小型自治服务来提高应用程序版本的速度。微服务架构也带来了一些挑战，这些模式可以帮助缓解这些挑战。设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。当然微服务中的云设计模式也是对微服务中普遍存在的问题，所提出的解决方案。我们是工程师，不是码农，所以小伙伴们，学习一个东西一定要深入一点，勿在浮沙筑高层，共勉！

             引用：https://azure.microsoft.com/zh-cn/blog/design-patterns-for-microservices/