乐是什么结构 环信首席架构师一乐 ：煎饼果子与架构模式

编者按:这篇文章由乐毅在高可用性架构小组中分享。请指出它来自高度可用的体系结构“ArchNotes”。

煎饼故事

在花园路住过一段时间，最难忘的是路边的煎饼果子。老板每天晚上都出来，正好赶上我加班。

往锅里撒一勺面糊，把刮刀转过去，再打一个鸡蛋，还是刮平。然后拍一下，抹上辣酱，撒上葱花。空出来剥个火腿肠。最后，把脆度放在上面，把三把铁锹切成三条直边的长方形，正好可以折叠在手里。辣，一口下去，鸡蛋味，辣酱，鲜肠，清脆的声音和葱花的惊喜，所有的疲惫都一扫而空。

就像我们谈论女人一样，

我们关心乳房，

关心腿，

在意风情，

在乎温柔，

因为女人不一样。

当我们欣赏电影时，

我们关心男人，

关心女人，

关心老人，

关心孩子，

因为角色不同。

当我们走在路上的时候，

我们关心行人，

关心车辆，

关心商店，

关心餐馆，

因为对象不同。

当我们设计和优化系统时，每个服务都独立运行，各司其职，但是在不同的维度上，它的功能就变得不同了。

这就是为什么我们说优化要分层次，分架构，分算法，分库，分OS。当我们谈论架构时，我们首先谈论整体模式，然后是具体的权衡，实现的细节是最不重要的。

建筑模式

这是因为马克·理查兹写了一本关于架构模式的书《软件架构模式》。

这本书总结和比较了五种模式的优缺点，包括分层、事件驱动、微内核、微服务和基于空间的。

文笔简单细腻，推荐阅读。地址见文末。

还有一种模式，因为在越来越多的系统中使用，书中没有(和天基不同)，但我觉得有必要具体介绍一下。我们开始在群发系统实施，后来经常在抢购、红包、火车票的场景中看到。

2013年我们在微博上做了一个粉丝服务平台，类似微信微信官方账号的群发系统。但是，比后者更难。当时的产品设计并没有像微信那样打造新的用户系统，而是直接基于微博的粉丝关系，也就是说一篇文章应该可以在短时间内支持上亿用户。这种数量级的订户，就算是看了今天的微信微信官方账号，还是难以想象。

当时有一个老的群发系统，是基于MySQL收件箱设计的。更换SSD硬盘和批量数据库操作后，整体写入性能依然只有每秒数万，也就是说1亿用户只能在17分钟内发送。我们意识到这个系统需要重新设计。

最后，我们使用了一种新的架构，达到了每秒百万的速度，还可以更高。这种模式就是单元化架构。

下面的介绍，我参考架构模式的解释方法，希望能给大家做个比较。喜欢就一定要说好！

单元化建筑

如前所述，选择单元化的一个重要目的是为了性能，以及极高的性能。相对于一般的分层架构，会得到更经济的效果，但也牺牲了分层架构的一些特性，因为它的容量取决于单元的大小(后面我会介绍一些单元等术语)。

虽然支持按单元扩容，但各层性能在单元内基本固定。这更适合于可预测容量的场景，例如，大多数已经变得稳定的业务。和之前的粉丝服务平台一样，他发的消息虽然巨大，但总体来说，因为平台的用户都是VIP用户，他们的规模基本都在百万，粉丝规模不太可能超过一亿。

重要的是，基于当时的业务数据，我们已经知道粉丝平均数量是多少个数量级了。业务数据是架构选择的重要依据。商品穗、火车票高峰等。都一样。

当然也有例外。因为单元化架构是一种理念，不会局限于一台机器，一个机架，也可以应用到一个机房。当它的等级变大时，单位内自然会有空的变化。每一层服务都可以单独扩展。在这个层面上，它的追求可能完全不同。像阿里双十一服务转型，会是为了流量分离，像QQ聊天，会是为了访问速度。他们的基本想法是一样的。

至于单元化结构和煎饼果子的关系，我后面会回答。

核心概念关键概念

分区(分片)是整个数据集的子集。如果用尾号划分用户，尾号相同的用户可以认为是同一个分区。

单元是一个独立的安装，它满足某个分区的所有业务操作。我们从并行计算领域借用了这个思路，也就是计算机体系结构中的Celluar Architecture，Cell是一个包含线程组件、内存和通信组件的计算节点。Https://en.m.wikipedia.org/wiki/Cellular_architecture(Cellize):这是我创造的词，描述了将服务转换成单元架构的过程。

模式描述

细胞结构最重要的概念是细胞和细胞自治。

你可以把它想象成一个细胞。如前所述，每个单元都是独立的，并且有明确的功能。你也可以把它想象成一个小隔间，就像你去按摩院，每个小隔间里都有技术人员和所有的设备。我没有用前者的名字是因为它有太强的生物学意义，我没有用后者是因为它有太多的服务含义。但是如果你有足够的想象力，你可以用任何名字。

说到单位自治，就是单位之间的自我协调和隔离。由于单元是自包含的，所以其中的所有组件，无论它们在物理上是否被分成独立的服务，都在一个单元中相互支持，即它们不会与其他单元中相同或不同的组件通信。这也是与基于空的体系结构的一个重要区别，在这种体系结构中，处理单元仍然相互通信并同步信息。

这里的挑战在于划分算法。一个单位会有很多组成部分，如果业务复杂，会涉及很多数据。为了隔离，每个组件必须根据相同的算法进行分区。

本质上，每个单元都是相似的，单元之间的差异取决于请求或数据。而且级别越高，区分度越低，用户甚至可以在不同的单位之间漫游。

模式动力学模式动力学

单元架构最典型的目的是实现高性能和高经济速度。这里我们一方面发现其他架构其实浪费了很多资源，每一层服务都运行在单独的操作系统上，必须通过局域网或者城域网进行传输。

同时，传统的互联网服务仍然希望用一堆具有普通计算能力的节点为大量用户服务。随着摩尔定律的推进，单机性能越来越高，网络通信成本变得显著。这给了我们在垂直方向扩张的机会和动力。

当你把更多的组件放在同一个地方，你也获得了物理上计算本地化的优势。这是我们业绩提升的根本原因。

服务分很多单元，但总是需要与外界沟通，这就交给协调员了。您可以在内部添加存储、缓存、队列和处理器。所有这些非交互组件理论上都是外部资源无法访问的。

前面说过，单元化过程也是划分算法的应用过程。而这个划分算法放在哪里是个问题。

我们可以将运行时封装到客户端，或者我们可以充当内置算法的代理层。还有一些服务因为业务需要需要复制到各个单元。这是典型的散点-盖特模型，所以你可能还需要一个作业管理系统。这些都是可选的使用方法。

模式分析

整体敏捷性、易部署、高可测性、高性能、高可扩展性、低开发。

出于篇幅的原因，我们就不一一细说了，相信大家可以自行分析。唯一需要强调的是，运维要求比较高。

单元化后，所有服务放在一起，需要在请求失败时快速定位一个单元，这与层次排除的思想不同。如果运维团队效率不够，面对这样的集群数量激增(单位服务数量相当于原集群服务数量)，可能会被大量的工作压垮；如果运维团队分离明显，每个组件都由专门的团队维护(我们在微博上遇到的)，就会有被拒绝的风险，因为每个团队都有自己的权限和服务管理习惯，需要相当的协调，防止相互干扰。

附笔

之前留下的一个问题是煎饼果子和单元化建筑的关系。答案很简单，问问煎饼摊就知道了。

煎饼分层，煎饼摊单元化。消息服务是单一的，但是索引维护是分层的。看模型来确定系统的范围，从不同的角度来看，同样的东西有不同的含义。这是建筑师应该思考的问题。其实IT系统有几百万，模型肯定不会就此止步。然而，对于基本模式，理解它们之间的异同有助于我们设计自己的系统并考虑权衡。

问答。A

1.单元化设计是否类似于Docker的集装箱化思想？有什么区别？

乐毅:应该是焦点不同，但没有冲突。Docker通常是一种将在微服务架构下使用的度量，但这并不意味着它不能在其他架构中使用。一个单元里的各种组件，用什么样的技术，都是新的选择。Docker不错。

2.对于分布式服务，单元化架构可能会带来数据一致性问题。如何解决这个问题？

易乐:可能我没看懂你的场景。单元化一般不会带来一致性问题。因为分片后，一个分区数据块相当于完全属于一个单元，其他单元是孤立访问的。

3.单元化架构的最小情况是单台机器部署整个服务。如何规划资源？

乐毅:这是关于计算，也就是容量规划，我相信大家都很熟悉。需要注意的一点是，当应用于可预测的整体容量时，单元化架构可以节省很多东西。鉴于固定和扩展分区算法，其实可以提前规划，在单台机器上混合多个单元。

4.单元和app集群的关联如何，是注册服务分配的还是hash分配的？如果是哈希分配的，挂了怎么接收？如果是注册服务，如何进行相应的分配？

乐毅:简单的是哈希赋值，高级点是注册服务，可以直接参考成熟的分片算法。任务只要到了单位，就是单位自己的事。如果您的作业有阶段，您可能需要考虑作业状态记录和请求处理的等同性

5.你认为单元化建筑的问题是什么？如果让你重新设计，你会做哪些改进？

易乐:这个问题太巧妙了，谢谢！如前所述，单元化架构的问题有扩展问题、运维问题和单点问题。如前所述，三年前我们没有Docker的时候，很难隔离我们的服务，现在也不是以前的样子了。Docker在手，我全世界都有！对于单元的单点问题，你要考虑单元层面的主从同步，这方面常用的互联网技术都可以。

6.分布式架构往往关注无状态的服务器，使得单个服务器的异常对整体服务没有影响。但是单位化意味着服务是有状态的。如何保证高可用性？

一乐:无国籍只能是业务层，数据不会是无国籍的，因为数据是状态的记录。保证高可用性，前面说了，先做主从。

7.你仍然在单元中采用层次化的架构设计，还是仅仅采用一体式架构设计？

乐毅:当谈到单位化时，单位中的组织模式是不需要的，所以答案是肯定的。

8.除了采用这种统一的架构模式之外，“每秒数百万次的推送”使其成为可能。队列db等基础中间件的架构是如何规划的？另外需要考虑哪些技术要点或问题？

一乐:排队主要是为了防高峰。在高速服务中，要想再次扩容，必须采取先批量的方式。其实db的规划才是重点，蜂窝架构其实就是一个以数据为中心的模型。其实额外的考虑和之前差不多，只是需要一些特殊的处理，比如冷热数据的分离。