why：
当系统的数据量、服务体量达到一定规模后，就会衍生各种问题，例如：系统的可扩展性、系统的稳定性等。
what：
一般公司都会经历从业务优先，到系统跟进完善的阶段。例如：单系统 -> 垂直扩展、水平扩展（如：两地三中心）。
垂直扩展模式：把全站应用、数据库等划分为几个部分，分别放在不同的机房中，完成一个业务可能需要不同机房中的不同应用提供服务。这就相当于在逻辑上把一个物理机房放大了，机房容量不足的问题得以解决。
水平扩展模式：每个机房中部署的应用都是相同的，每个机房都有完成全站所有业务的能力，在运行时每个机房都只承担整站的一部分业务流量。
在实现上，垂直扩展模式更容易一些，能够突破机房容量瓶颈，但是不具备容灾能力，而容灾，是一个发展到一定规模的互联网系统很重要的一个诉求，因此大多数大型系统都采用多机房水平扩展模式。水平扩展模式，要解决的首要问题是，如何把业务流量分配到多个机房中去，并且能够动态的、实时的自由调配。其次一个，也是最难的问题是数据分割，每个机房都可以很容易的拥有各自独立的应用集群，因为应用通常是无状态的，但是数据却不行，要做到所有机房仅访问自己的数据，互相之间没有交叉，是挺困难的一件事，特别是有些全局公共的数据，甚至是完全没办法拆分开的。
容灾问题，对于一个有着亿级用户的系统、或一个数据型系统来说尤为重要，仅仅是机房级容灾还不够，必须要考虑部署地容灾，也就是说不能把所有机房部署在地理上临近的地区，以防发生地震、海啸、核爆等剧烈灾害而导致系统被毁灭性破坏。这些系统的典型代表是银行、第三方支付等金融类系统，比如银行业就对机房部署有着经典的“两地三中心”要求。
多中心部署，就会带有“距离的问题”。距离下面隐藏着的是延时，更远的距离意味着更长的延时，个位数毫秒的延时不会给系统带来什么麻烦，但一旦这个数值变成十几毫秒，甚至几十毫秒时，量变就引发了质变，很多业务开始不能忍受和忽略延时带来的影响。
how：
单元化：
多地多机房部署，是互联网系统的必然发展方向，一个系统要走到这一步，也就必然需要解决上面提到的问题，流量调配、数据拆分、延时等。有很多技术、方案可以用来解决这些问题，而承载这些方案的是一个“部署架构”。在各种部署架构中，“单元化部署”一般都比较推荐。
所谓单元（Cell），是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。单元化部署就是把单元作为部署的基本单位，在全站所有机房中部署数个单元，每个机房里的单元数目不定，任意一个单元都部署了系统所需的所有的应用，数据则是全量数据按照某种维度划分后的一部分。
对比传统的SOA部署（如下），服务是分层的，每层的节点数量不尽相同，上层调用下层时，随机选择节点。
单元化部署，
标签：演化,扩展,分区,系统,部署,机房,延时,单元 From： https://www.cnblogs.com/sfzlstudy/p/17730211.html