引言
钉钉单元化从年开始到今年已经是第五个年头了，五年的时间，钉钉单元化迭代了三个版本，从最初的毛头小子，到达今年已经小有成就。今天想借这个场来和大家分享我们单元化的心路历程和一些最佳实践。本文要分享的内容只涉及部分内容，无法做到面面俱到，主要是想在同路人中形成共鸣，进而能复用一些架构或者系统。在我们单元化建设过程中，除了网上仅有的文章外，其可以直接使用的系统乏善可陈，使我们不得不从最基础的系统开始，极大的影响建设效率。幸运最近几年云原生技术的兴起，让我们能复用很多基础设施，进而快速的提升我们单元化能力，助力钉钉的发展。
单元化1.0
合规驱动下的部署架构
年，部分大客户出于法律政策、商业机密数据存储的要求，要求钉钉的数据存储、访问接入、服务部署需要在其信任的区域内，既需要满足其数据存储私有化要求，同时需要满足跨地区网络的rt性能要求。结合阿里云机房部署位置、物理距离、用户数据安全等方面出发，钉钉在客户的阿里云机房内建设了一个单元，将通讯录、IM信息等企业数据单独存储在客户机房。
我们通过一条专线，将两个机房逻辑串联到一起，内部通过DMB/DMR系统，实现了请求互通。钉钉单元化1.0比较简单，纯粹是业务驱动，和支付宝单元化建设的初衷：容灾驱动有较大区别。两个站点通过UID分段，将用户划分为中心用户和专有用户。上图只是一个简化的逻辑结构，内部实现远比上图复杂，但是1.0建设主要是从0到1，和大多数异地多活的系统相似，简单和大家分享。
单元化2.0
2.1被逼的容量架构
年是一个特殊的年份，由于疫情的原因，带给大家非常多的改变，其中也包括钉钉。由于在线办公与教育流量的突增，开年第一天上班就给钉钉一个下马威，平峰的流量已经和除夕跨年的持平，但是和除夕不同的是这个流量是持续的，即使节前准备了三倍容量，也抵挡不住流量对系统的冲击。只能借助阿里云的能力，不断的扩容。
但是每天将近30%的流量增幅，单纯的扩容也能难保障服务的连续性，最终也遇到了扩无可扩的场景，张北机房没有机位了，有机器资源但是没有机位让我们有力无处使。我们不得不不断进行系统优化，同时借助限流、降级、双推等措施，勉强抗住了流量的最高峰。
疫情之前，我们一直在做高可用，但是这个高可用主要集中在容灾机制上，比如搭建容灾单元。如同支付宝一样，是因为当时光纤被挖断；又比如银行的两地三中心架构，是担心某一个地域由于天灾或者战争导致数据丢失。疫情的流量给我们上了一课，仅仅