朱烨的Internet体系结构实践经验S1E7: 三十种体系结构设计模式（上）

朱烨的Internet体系结构实践经验S1E7: 三十种体系结构设计模式（上）

[下载此PDF以供阅读]

设计模式是一些实践的总结和最佳实践. 经过多年的软件开发实践，回顾23种设计模式，您会发现许多用于编写代码的例程与OO例程和设计模式中概述的例程相似，这些例程还显示了您学到的知识和其他知识. 据了解，经过大量的实践，我们总是可以得出最佳实践的一些结论. 架构设计也相同，这里结合他们自己的理解来分析Microsoft提供的一些云架构模型. 据说微软真的很擅长这样做. 先前翻译的“ Microsoft应用程序体系结构指南”也非常好. 拥有模型的优势在于，可以通过几个模型关键字轻松地交换技术人员和技术人员之间的对话，就像现在每个人都提到责任链模型一样，如果双方都理解了该模型的含义，那么这五个词可以替换为半小时的解释. 事不宜迟，让我们看一下这些熟悉的模型.

进程外代理服务（如先前在介绍中间件时所述，许多框架级的东西可以以软件框架的形式托管在进程中，或者可以以独立代理的形式成为网络中间件） . 这里的大使模式意味着这种网络代理过程用于与远程服务进行通信并完成以下工作:

由于它是一个独立的流程网络服务，因此该模型适用于具有多种语言和多种框架并且需要做同一件事的我们. 然后，可以将我们框架的客户端部分中的许多工作移交给大使服务. 当然，还有一层网络呼叫和一层额外的开销. 大使服务的部署还必须考虑到性能可能不集中. 这些都是要考虑的问题.

使用一层防腐蚀层充当新旧系统之间通信的中间人. 这样，新系统可以完全使用新的通信方法和体系结构，并且可以在不进行特殊修改的情况下临时保留旧系统，并且可以在不使用旧系统后丢弃反腐败层. 此模式适用于新旧系统迁移的过渡计划，它不是永久使用的体系结构设计模式.

此模式表示可以使用外部配置服务来保存配置信息. 在介绍中间件之前的第五篇文章中，我详细介绍了配置服务的功能. 无论是从管理，运营和维护的角度，还是从便利性和安全性的角度来看，具有配置共享配置和外部存储特性的独立配置服务对于大型网站都是必不可少的. 如果实现了，则有许多提供配置服务的开源项目，请参阅我的上一篇文章.

如果应用程序需要与多个服务交互，则在中间构建一个聚合网关层. 网关将多个请求同时发送到后续服务，然后将数据聚合到应用程序. 此模型有几个好处:

当然，使用此模型需要考虑网关的负载，高可用性，高性能（异步IO）等.

实际上，此模式不仅用于纯后端服务之间的通信. 许多前端API请求将是一个聚合层，因此，当仅发送一个请求时，前端可以从后端任意请求更多请求. API的返回减少了网络请求的数量并提高了性能.

最简单的方法是使用OpenResty或Nginx.

这个名字有点难以理解，实际上，我们可能一直在使用这种模型. 它是使用代理网关层来执行一些与业务无关的麻烦事情网络设计模式，例如SSL. 使用Nginx实施非常简单. 我们通常会在外部启用HTTPS服务，然后内部服务实际上会提供HTTP接口，并通过网关进行协议转换.

这也是很常见的做法. 我们的外部接口可能是/ cart，/ order，/ search等API. 实际上，它们背后是不同的服务. 通过网关层转发不仅是一种后端服务. 对于负载平衡和故障转移，我们还可以在后端服务更改时执行灵活的路由，并切换外部API路径（例如版本升级），以确保外部接口的一致性. 可以使用Nginx来实现. 可以相信，大多数公司都是通过Nginx之类的网关进行外部化的，不会将域名直接解析为基础服务.

此模式实际上非常重要. 有几点要注意:

在实现方面，我们应该将运行状况端口作为插件形式集成到系统中，并且可以在配置后启用它. 每个系统不必开发自己的集合. 如果使用Spring Boot，则可以直接使用Actuator模块.

这个名字很吓人，这个模型是关于如何进行迁移的. 通过建立立面作为后端新旧服务的路由，用新服务缓慢替换服务，最后在所有服务都是新的时删除立面. 这样，消费者无法感知到此迁移过程. 在上一篇文章中，我们提到了更改引擎的方法实际上是保留原始外观，并通过该外观替换基础引擎. 实际上，我认为这种减少外部影响的模型是理所当然的. 真正困难的过程是数据迁移和基础服务的实现过程.

此模型不是广义上的高速缓存使用，而是其中之一. 我们通常以几种方式使用缓存:

此模式是后一种方式. 对于较小的数据更改，此模式具有最佳的性能，几乎100％的命中率，并且如果数据量不足以容纳该过程，则没有必要. 跨进程通信. 要仔细考虑一下，这里有一层性能优化，因为我们维护着一组复杂的数据结构，其中的全部数据都在内存中. 对内存中对象的引用只是指针引用，并且内存中的数据搜索可以非常快. 对于数据量少但关系复杂的数据，此搜索效率可以是的数百倍. 在实现中，将在启动应用程序时将数据完全添加到内存中，并在将来通过某些策略更新数据:

英文缩写为CQRS. 您可能对此关键字有点熟悉. CQRS最初表示，我们可以有两组数据模型用于读写. 好处是我们可以使读写具有完全不同的数据结构，减少相互干扰，并降低权限控制的复杂性. 这并不一定意味着我们可以在体系结构级别上做到这一点. 这也意味着在程序中，我们可以有两组命令模型来处理读写的两件事，并分别对其进行优化和自定义.

现在，一般方法类似于上图中所示的方法. 将两个单独的数据源配置为用于读取和写入，并与事件可跟踪性方法结合使用（请参阅以下部分）. 让我们谈谈两组读写模型在存储中分开的事实. 在“补充存储五件套”一文中，我们的体系实际上具有此含义. 对于阅读和书写这两个方面，我们可以完全使用一组数据源来创建一个专门的物化视图以进行阅读，可以对其进行优化以进行阅读，从而避免在阅读时进行大量的Join工作，并且可以最终实现性能（稍后将介绍物化视图模式）. 事件跟踪+ CQRS +实例化视图通常结合使用.

事件跟踪（ES）是一个有趣的模型. 据说我们记录的不是数据的当前状态，而是数据变化的叠加顺序（是否考虑了区块链数据记录方法）. 由于传统的CRUD方法具有更新操作，因此在性能并发方面将受到限制，并且我们需要配备其他日志以进行审核，否则会发生信息丢失. 事件跟踪模式记录事件而不是当前状态，因此具有以下特征:

实际上，在某些业务场景中，此模型比CRUD存储更合适:

相反，具有非常简单的业务逻辑的系统需要具有高度一致性的系统，而数据更新很少的系统不适合此模型. 我不知道您了解采用ES模型的哪些业务方案？让我们一起聊天.

当我们使用数据存储时，我们倾向于更多地考虑存储而不是读取. 我们使用各种范例来设计. 读取数据时，我们需要进行很多相关查询以输出满足需求的查询结果. 此时，性能通常成为瓶颈，物化视图是一种时空方法. 与其在查询过程中进行关联，不如先保存一种数据格式以用于查询和输出，而不是在查询过程中进行关联. 因此，物化视图适用于以下情况:

但是由于需要考虑实例化视图计算和存储的成本，因此它也不适合数据更改过于频繁的情况. 因为数据处理需要时间，所以它不适用于需要强数据一致性的方案.

该实现通常基于消息监视，以实现一组物化视图数据源的额外维护以及主流程的解耦. 惠普的Vertica是高性能的柱状分析. 它的功能之一是物化视图. 通过预先提供SQL语句以直接缓存查询结果以进行统计，它可以极大地提高性能，也是一个时空观念.

我们对消息队列太熟悉了. 我们之前曾多次对其进行过多次改进，甚至我说过这是建筑的三大支架之一. 该模型在这里强调了峰值削波的优势. 在这里，我还想提及几点:

与FIFO结构队列不同，优先级队列允许消息标识处理优先级. 有两种方法可以实现上述两张图片:

在方案的选择和实现中，有必要考虑是否需要以绝对优先级或相对优先级来处理消息优先级. 如果需要绝对优先级，则除了消息位置重新安排之外，还需要抢占处理. 另外，如果我们使用第二种多池方法进行处理，则可能发生以下情况: 如果两个流程业务逻辑完全不同，则低级消息的处理时间要比高级别消息的处理时间快.

在实现方面，RabbitMQ 3.5及更高版本支持消息优先级. 实现第一种方法. 缓冲消息后，将重新排列消息. 消费者可以看到具有最高优先级的消息首先被处理. 这样，在消耗速度大于输出速度的情况下，无法实现高级消息优先级处理.

此外，对于队列中的消息，还需要特别考虑，应将队列中已存在的消息视为低优先级或死信消息，最好由单独的使用者处理. 为了防止此类消息影响整个队列的处理，发生了很多事故，因为队列中的废弃消息被卡住并且处理能力完全丧失了.

进行压力测试时，我们会发现，随着压力的升高，系统的吞吐量逐渐增加，响应时间基本上可以控制（在1秒以内）. 当压力突破边界时，响应时间突然变得不可控，系统的吞吐量下降，最后完全崩溃. 任何系统都有压力负载的限制. 超过此限制后，系统的SLA当然将不符合该标准，因此每个人都无法正确使用此服务. 由于通常无法在几秒钟内完成系统扩展，因此目前最快的方法是限制电流. 只有有限的电流才能保护电流系统不超过该边界并完全崩溃. 对于具有大业务量的系统，不可避免地要限制关键服务的流量，甚至是入门级别. 没有别的办法了. 淘宝网Double 11可以看到一定比例的订单被限制在上午0:00.

有几种常见的限流算法:

令牌桶算法限制了平均流入速率，从而允许一定程度的突发请求，而泄漏桶算法限制了用于平滑流入速率的恒定流出速率. 在实现中网络设计模式，一些常用的开源库将具有相关的实现，例如Google的Guava提供的RateLimiter是令牌存储区算法.

当前限制模式具有以意事项:

在下一篇文章中，我们将继续介绍数据，安全性，消息传递和弹性方面的一些架构模式.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-280673-1.html