前言

由于历史原因，集中式架构多用于传统银行、电信等行业。主机资源集中在大型主机或小型机上。集中式架构下，包括操作系统，中间件，数据库等“基础软件” 均为闭源商用系统。集中式架构的典型案例是 IOE（IBM， Oracle，EMC）提供的计算设备、数据库技术和存储设备共同组成的系统。

近年来，分布式架构在 Google、 Amazon、Facebook、阿里巴巴、腾讯等互联网公司广泛应用基础上、也越来越多被金融行业关注和应用。分布式架构一般采用性价比更高的 PC 服务器、分布式数据库和大量 PC 内存闪存，程序同时运行在众多 PC 服务器上。

考虑的点

下面就来看看从现有架构升级为分布式要考虑哪些方面的内容。

【数据库】

一个典型的互联网应用，前端服务器可以利用负载均衡服务，组成一个集群，但是只有一个mysql主库，这时候，mysql服务就是系统中依赖的关键服务。

关键服务的性能和波动将成为整个系统的性能瓶颈和主要问题源。

为了减轻只有一个mysql主库的依赖，我们引入了一主多从的架构，让更多从库也来提供查询服务，减轻主库的查询依赖。

这样升级改造后，系统的性能和稳定性还是有明显的提升，但是mysql查询的复杂度和数量增加后，mysql的性能瓶颈依然会很突出。

【缓存层】

于是，继续升级，引入redis或者memcache，将大量的结果缓存起来，把应用尽量从mysql隔离，减少对数据库的依赖。

这时候，我们会欣喜的发现，应用的性能比之前完全依赖mysql的时候要强好多，稳定性也响应的提高很多。

随着我们的系统越来越复杂，访问量越来越大，缓存层的压力也会越来越大。

一方面是内存不足的问题，另一方面数据更新更复杂，还有就是访问压力以及内网带宽的瓶颈也增加了。

这时候又要开始对缓存层继续升级改造了，于是分布式缓存集群也就出现了。

通过一致性hash算法或者简单的散列方法，都可以很容易的增加redis/memcache服务来构建更大规模的集群。

这样一来，随着服务器增加，单机的内存瓶颈减轻了，访问压力以及带宽压力也降低了，但是数据更新的问题依然存在。

数据更新的问题，就是数据不一致的问题，本质上就是因为一个数据的多次写入，中间出现异常的话，就导致出现不一致了。

关于数据一致性问题，我们后面再来详细分析和讲解。加群895244712了解更多架构升级知识。

随着缓存层集群的构建，整个系统架构就变成了多前端服务器，多缓存服务器，一个主库，多个从库。

主库主要承载数据写入的负载，在大部分的互联网应用中，写入的数量相对还是少很多的，所以大部分时候，这样的架构也就可以安枕无忧啦。

【更大规模】

我们的追求不仅是眼前的苟且，还有更强大的系统和更多的用户。

当我们的应用，用户数、访问量过千万之后，以前的架构还是会遇到越来越多的挑战。

这里面，可能数据库还是会第一个出现瓶颈，毕竟一个主库，再强大也是没法做到一秒钟数万次的更新，哪怕只是小小的点击数的增加。

这时候，就要开始考虑对数据库做分拆了，把一个数据库分拆为好几个数据库（分表分库）。

而分拆的方式，大家应该能想到的，比如：水平分拆和垂直分拆。

【水平分拆】

典型的水平分拆就是对数据做归档，按照日期（每年归档），把旧的数据迁移到归档库里面，访问量少，也不会有写入的压力。

水平分拆对整个系统的改造和变化相对来说是影响比较小的，毕竟数据结构没有变化，只是数据源增加了。

而这种分拆带来的明显效果就是，数据规模减少，数据库的读写性能都会有明显的提升，当然对整个应用的性能和稳定性都会有很大提高。加群895244712了解更多架构升级知识。

【垂直分拆】

如果只是对数据库做垂直分拆，只是把一部分数据表迁移到其他独立数据库中，比如：把用户相关的信息表迁移到用户库，把商品相关的产品表迁移到商品库，那这个分拆也不算难。

但是，往往伴随着系统规模的变大，应用的复杂度也会不断提高。

所以，这个时候垂直分拆，很可能会同时进行应用的分拆。

比如：把用户的登录注册、信息维护单独部署和维护，把商品信息的管理和维护单独部署。

这时候，应用也就同时进行了垂直分拆，即：把大的应用进行组件化、服务化。

【微服务】

到这个阶段，大家应该就开始感觉大一个系统的复杂了吧。

一开始说好的做一个互联网应用，而现在却出来了很多个应用和服务，他们之间又有很多关联，组成一个大型的系统。

这时候，系统中的关键服务依赖已经不仅仅是缓存层、数据库服务，而变成了一个个拆分之后的应用、微服务了。

这时候，系统的性能和稳定性就完全依赖各个微服务的性能和稳定性了。

如果，再把每个微服务按照上面的架构升级路线演练一遍，貌似又不那么困难。

但是，全部组合在一起，新的难点已经是对这些服务的监控、运维、故障排除等治理工作。

想要了解更加深入、细节的分布式架构系统吗？这些分布式架构都是如何实现的？集中式架构升级为分布式架构会遇到哪些坑？欢迎加群895244712，这里有详细完整的大型分布式架构系统架构经验，等你来取。

未来的架构是什么样？

那么，系统继续升级的话，我想，可能就是自动化运维的工作会更多了吧。

• 一两个数据库宕机不用怕，主从自动切换，数据库集群秒级自动恢复。
• 几个缓存服务器网络不稳定也没关系，有备份的缓存可以先用着。
• 微服务的一些服务器不稳定，服务自动降级，并且在微服务稳定后自动恢复以及同步数据。
• 甚至一个机房断网、断电了，其他机房依然正常的提供全面的服务，不影响用户使用。

总结

分布式架构在经济性、安全自主、灵活性、可伸缩性等方面有明显优势，随着系统需要处理的交易量与数据量越来越大，分布式架构在这方面的优势也会越来越明显。集中式系统在可维护性、一致性方面有优势，而分布式系统需要达到同等或更高的可维护性与高一致性，需要通过先进的分布式中间件与大规模运维平台来支持。

• 关键服务依赖总是最重要的环节，也是最容易出问题的地方。
• 系统架构升级，正是对这些关键依赖的瓶颈进行针对性优化升级和改造。
• 应用从小变大，再分拆变小，从一个应用到很多个微服务，这些都是技术不断变革的过程。
• 规模化带来了带来了的总体容量和总体性能的提高，同时也带来了关于服务治理的新挑战。

那么，是不是开发系统都要用这么复杂的架构呢？

其实不是，上面的架构升级过程，其实是对线上问题不断发现和解决的过程，也是一个不得已的过程。如果一个系统的用户量、业务量不大，一开始就复用一套庞大的系统架构，那真的就费时费力，累死自己，完全没必要。所以，合适就好。