单元化架构
目录
编辑
单元化
逻辑单元
单元化
多地多机房部署，是互联网系统的必然发展方向，一个系统要走到这一步，也就必然要解决上面提到的问题：流量调配、数据拆分、延时等。业界有很多技术方案可以用来解决这些问题，而承载这些方案的，是一个部署架构。尽管可采用的部署架构不止一个，但不论是纯理论研究，还是一些先行系统的架构实践，都把“单元化部署”推崇为最佳方案。
单元（即单元化应用服务产品层的部署单元），是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。单元化架构就是将单元作为部署的基本单位，在全站所有机房中部署多个单元，每个机房内单元数目不固定，任一单元均部署系统所需的全部应用，数据则是全量数据按照某种维度划分后的一部分。
传统意义上的 SOA 化（服务化）架构，服务是分层的，每层的节点数量不尽相同，上层调用下层时，随机选择节点。
单元化架构下，服务仍然是分层的，不同的是每一层中的任意一个节点都属于且仅属于某一个单元，上层调用下层时，仅会选择本单元内的节点。
一个单元，是一个五脏俱全的缩小版整站，它是全能的，因为部署了所有应用；但它不是全量的，因为只能操作一部分数据。能够单元化的系统，很容易在多机房中部署，因为可以轻松将多个单元部署在一个机房内，而将另外几个单元部署在其他机房内。通过在业务入口处设置一个流量调配器，可以调整业务流量在单元之间的比例。
从上述对单元的定义和特性描述中，可以推导出单元化架构要求系统必须具备的一项能力：数据分区，实际上正是数据分区决定了各个单元可承担的业务流量比例。数据分区（shard），即是将全局数据按照某一个维度水平划分开来，每个分区的数据内容互不重叠，这也就是数据库水平拆分所做的事情。
仅把数据分区了还不够，单元化的另外一个必要条件是，全站所有业务数据分区所用的拆分维度和拆分规则都必须一样。若是以用户分区数据，那交易、收单、微贷、支付、账务等全链路业务都应该基于用户维度拆分数据，并且采用一样的规则拆分出同样的分区数。比如，以用户 id 末 2 位作为标识，将每个业务的全量数据都划分为 100 个分区（00-99）。
有了以上两个基础，单元化才可能成为现实。把一个或几个数据分区，部署在某个单元内，这些数据分区占总量数据的比例，就是这个单元能够承担的业务流量比例。 执行数据分区时一个很重要的问题是分区维度的选择，一个好的维度，应该：
-
粒度合适：粒度过大，会丧失流量调配的灵活性和精细度；粒度过小，会给数据的支撑资源，访问逻辑带来负担。
-
足够平均：按这个分区维度划分后，每个部署单元的数据量应该是几乎一致的。
以用户为服务主体的系统（很多面向用户的系统，比如支付宝）通常可以按用户维度对数据分区，这是一个最佳实践。
逻辑单元
逻辑单元是单元化架构的基础，一个单元被称为一个 Zone。根据业务特点不同，您可以将系统部署在不同类型的逻辑单元中。更多信息，请参考 创建逻辑单元。
参考：
什么是单元化原理,如何实现单元化_金融分布式架构(SOFAStack)-阿里云帮助中心
支付宝资深技术专家尹博学：新一代金融核心突破之全分布式单元化技术架构-阿里云开发者社区