大使模式：构建一个辅助服务，代表消费者使用服务或应用程序发送网络请求。

进程外的代理服务（之前介绍中间件的时候也提到了，很多框架层面的事情可以以软件框架的形式寄宿在进程内，也可以以独立的代理形式做一个网络中间件）。这里的大使模式意思就是这么一个网络代理进程，用于和远端的服务进行通讯，完成下面的工作：服务路由、、服务熔断、服务跟踪、服务监控、服务授权、数据加密、日志记录。由于是独立进程的网络服务，所以这个模式适合于我们有多语言多框架都需要干同样的事情，那么我们的框架中客户端部分的很多工作可以移出来放到大使服务中去。当然了，多一层网络调用多一层开销，大使服务的部署也要考虑到性能不一定可以集中部署，这些都是要考虑的问题。
 

反腐模式：是通过引入装饰或适配器层来实现现代应用程序与遗留系统之间的集成。

可以使用一层反腐层来作为新老系统之间通信的中间人，以实现平滑过渡。这种过渡方案允许新系统完全采用新的通信方式和架构方式，同时老系统无需进行特别改造并可以保持运行，只需引入反腐层来进行通信协调。当老系统不再需要时，可以废弃这个反腐层。这种模式适用于新老系统迁移的过渡阶段，并不是永久性的架构设计模式。

外部配置存储：将应用程序中的配置信息从部署包中移动到一个中心化的地方进行存储。

这个模式说的就是可以有一个外部的配置服务来保存配置信息，在之前文章介绍中间件的时候我详细说明过配置服务的功能。不管是处于管理运维的角度还是方便安全的角度，具有配置共享配置外存特点的独立配置服务对于大型的网站来说必不可少。实现的话有很多开源项目提供了配置服务。

网关聚合模式：使用网关将多个单独的请求聚合到一个请求中

应用程序如果需要和多个服务交互的话，在中间构建起一个聚合网关层，网关并发发出多个请求给后面的服务，然后汇总数据给到应用程序。

这种模式有几个好处：
允许并发调用多个服务提高性能，
允许只返回部分数据网关里可以做一些弹性设计方案（熔断、重试、限流）
网关里可以做一些缓存方案对于外网通讯的时候，
可以让网关作为一个网络中间层当然，使用这种模式需要考虑到网关的负载、高可用、高性能（异步IO）等等。
其实这种模式不仅仅用于纯后端服务之间的通讯，很多面向前端的API请求都会做一个聚合层，这样前端可以只发一个请求的情况下任意向后端一次性索取多个API的返回，减少网络请求次数提高性能。

实现上最简单的方式可以使用OpenResty或Nginx实现。
 

网关卸压模式：把共享或特定的服务功能放到网关代理

名字有点难以理解，其实这种模式我们可能一直在用。就是用一个代理网关层做一些和业务无关的又麻烦的点，比如SSL，实现上用Nginx实现就很简单。我们经常会对外启用HTTPS服务，然后对内服务实际提供的是HTTP接口，通过网关做一下协议转换。

网关路由模式：使用单个端点将请求路由到多个服务

这也是很常见的作法，我们对外的接口可能是/cart、/order、/search这样的API，在其背后其实是不同的服务，通过网关层进行转发，不仅仅可以做后端服务的负载均衡和故障转移，在后端服务变更切换对外API路径（比如版本升级）的时候我们也可以进行灵活的路由，确保了对外接口的一致性。可以使用Nginx来实现，相信大部分公司都是由Nginx这样的网关来对外的，不会把域名直接解析到底层服务上对外。
 

健康端点监控模式可以理解为应用程序内部的功能检查，通过暴露端点给外部工具访问，以定期监测应用程序的健康状况。
 

1. 暴露服务依赖的外部存储或系统是否可用的信息。这样可以更全面地判断服务的健康状态，而不仅仅是检查服务本身或框架是否启动成功。由于网络通信的复杂性，仅凭服务是否可用并不能代表整个网站可以成功连接。因此，我们需要检测底层数据库等外部存储是否正常连接。同时，即使对于某个节点可以正常连通，但对于其他节点可能由于网络问题、权限问题或负载问题而无法连接。因此，在可能的情况下，还应该暴露服务内部各种线程池、连接池和队列的信息，如对象数量、队列长度等。这些关键指标的外露对于排查性能问题非常有帮助。

2. 服务健康信息的暴露。服务应该提供健康信息，以便在外部进行监控和统计。此外，负载均衡器或发布系统也需要一种方式来判断服务是否可用，以便在不可用时进行重启或故障转移。需要注意的是，对外的服务的health端口应进行授权，以防敏感信息被匿名用户访问到。

3. 实现上的考虑。推荐将health端口作为插件形式集成到系统中，并进行相应的配置即可启用。这样做的好处是避免每个系统都开发一套健康检测机制。如果使用Spring Boot框架，可以直接使用Actuator模块来实现健康检查功能。
 

绞杀者模式：通过使用新的应用程序和服务逐渐替换特定功能部件来逐步迁移旧系统

这个模式是一种逐步替换旧服务的方法，通过建立一个门面作为新老服务的路由来实现。

在迁移过程中，逐步将旧服务替换为新服务，并在最后所有服务都迁移完成后删除该门面。

这样可以确保消费者不会感知到迁移的过程，减少对外围系统的影响。

在之前的文章中我们提到的引擎替换方式也是通过保留原有门面来进行底层引擎的替换。

对于减少外围影响这种模式确实是一个常见且合理的解决方案，但实际迁移过程中还需要重点考虑数据迁移和底层服务的实现等方面的挑战。

关注公众号：领取架构师面试资料