汇付天下钛客头条 | 关于单元化架构，满满干货和经验之谈
发布时间：2019-12-10 15:43浏览次数：
业内有这么一句话：业务的高可用架构最关键的目标是数据不丢，业务不停。
随着公司的不断发展，服务场景不断延伸，我们对于业务高可用、高性能、一致性场景方面的要求就在逐渐提高，底层系统应用也在经过几代应用架构的演变之后，慢慢形成了现在的单元化架构。
今天，小钛带领大家一同来了解看看，我们汇付天下的单元化架构演进之路，满满都是实操干货和经验之谈。
其实，从应用服务架构本质来说，从本地服务，到远程服务，再经历SOA、ESB、微服务、到最新的Service Mesh技术，服务一直在解决的是单个实例最小细力度上的问题。
但单元化架构从业务所涉及到的所有外部依赖，从整体的角度来架构和规划，解决的是最终业务的高可用、高性能、一致性的场景，而不是简单的某个应用服务集群。
（Via 网络，侵删）
洋葱细胞的显微镜截图，单元化要达到的目的就是让每个单元像细胞一样独立工作
因此，我们可以简单理解为，单元化的核心是不把鸡蛋放到同一个篮子里面，而是把业务划分出各个逻辑的单元，可以把它们放到各个地方，各个系统之间也没有过强的依赖，当某一个地域出现问题之后，不会影响到其他地方，只需要把流量切换一下就可以了。
同时，按照业务的维度，我们可以把业务划分成各个逻辑单元。但如果发生跨单元调用，延时也会比较长，最终对于用户使用体验来讲是非常差的。所以要遵循单元封闭的逻辑，让每一个单元内的调用关系都封闭在自己的单元内，不要发生跨单元的调用。
单元化最大的难点是集中化存储，这里面包括共享内存 Redis、MQ迁移、文件存储、数据库存储……其中，数据库存储的拆分（数据按业务模式拆分）和整合（数据汇总）是最大难点。
每个业务系统在同一个机房区域内需要有自己的数据，在某个网络区域内需要有自己的数据库，最终在单个 VM 和 Docker 节点上要有自己的数据，当一个区域挂掉后，数据会自动同步不影响另一个区域服务使用。
单元化数据拆分与整合，可以从业务层和系统层面去考虑。
从业务层面去拆分耦合的数据，使其业务能在最小单元内可用。最常用的手法就是通过业务场景，对入口数据进行业务拆分，拆分的手段一般有 Hash、指定业务数据规则，最终对应的数据以耦合最低的方式落地到可用单元区域。
从系统层面，最小化数据同步延迟，最大程度容错处理，就是两地数据库通讯加速，两地数据的高可靠性加强。这个可能就使得在硬件层面需要投入巨大成本。
而使用数据库来进行数据拆分，一种是依赖分布式数据库中间件，如阿里云 DRDS 或开源的 sharding-sphere、sharding-jdbc 、Mycat 等等；还有一种依赖数据库自身的能力，与中间件深度结合，如阿里云的 OceanBase，本身在支持异地多副本一致性，低延迟及良好的灾备；这种好处在于，业务层不需要过多关心数据层多地部署，对业务单元化来说是一个很好的方式，但从成本上可能比较昂贵。
数据的整合，因为有拆分必然需要整合。这里的整合对业务来说，一般有每个单元都要用到的业务数据，还有事后需要数据汇总的数据，还有一类事物强一致性数据（如金融账务数据、电商库存数据），则必须要建立主单元中心。
对于单元中的数据恢复，则需要建立一个共享中心单元，用做数据在各个单元之间的数据同步。
以上解释了单元化的基本概念，但单元化不是一蹴而就的，我们在公司的单元化架构演进过程中，也得出了一些方法和经验。
单元化架构的演进，是一步一步来的，为什么这么说呢？因为公司业务的增长各有不同，对系统高可用的要求，对数据的一致性要求，对请求的吞吐量要求，也都不同，本质还是ROI的回报问题。
最后，我们还需要关心的是，单元化架构之下的发布、监控、容灾、弹性，也发生了具体的变化，那么该如何去实施与运维，也是我们需要重点去考虑的。
汇付天下单元化架构的基础，是基于我们自研的单元化中间件API网关和微服务框架 Pegasus，实现单个机房内应用级别的深度隔离和容灾。
随着业务场景和要求的不断变化，还需要我们的架构师们做持续地探索和研究。
