学习分布式系统架构1

随着互联网的快速发展，传统的单体系统架构已不能满足海量用户的需求。于是，更多的互联网企业开始对原有系统进行改造和升级，将用户产生的大规模流量进行分解，分而治之，在不同的服务器上为用户提供服务，以满足用户的需求。慢慢地，由原来的单体系统架构演变为分布式系统架构
产生的背景
在互联网早期，互联网企业的业务并不是很复杂，用户量也不大，一般使用单体系统架构快速实现业务。此时，系统处理的流量入口更多来自PC端。
随着用户量爆发式增长，此时的流量入口不再只有PC端，更多来自移动端App、H5、微信小程序、自主终端机、各种物联网设备和网络爬虫等。用户和企业的需求也开始变得越来越复杂。在不断迭代升级的过程中，单体系统变得越来越臃肿，系统的业务也变得越来越复杂，甚至难以维护。修改一个很小的功能可能会导致整个系统的变动，并且系统需要经过严格测试才能上线，一个很小的功能就要发布整个系统，直接影响了系统中其他业务的稳定性与可用性。
此时开发效率低下，升级和维护系统成本很高，测试周期越来越长，代码的冲突率也会变得越来越高。让人头疼的是，一旦有开发人员离职，新入职的人需要很长的时间来熟悉整个系统。单体系统架构已经无法支撑大流量和高并发的场景。
面对单体系统架构的种种问题，解决方案是对复杂、臃肿的系统进行水平拆分，把共用的业务封装成独立的服务，供其他业务调用，把各相关业务封装成子系统并提供接口，供其他系统或外界调用，以此达到降低代码耦合度，提高代码复用率的目的。此时，由于各个子系统之间进行了解耦，因此对每个子系统内部的修改不会影响其他子系统的稳定性。这样一来降低了系统的维护和发布成本，测试时也不需要把整个系统再重新测试一遍，提高了测试效率。在代码维护上，各个子系统的代码单独管理，降低了代码的冲突率，提高了系统的研发效率。
架构目标和架构原则
好的分布式系统架构并不是一蹴而就的，而是随着企业和用户的需求不断迭代演进的，能够解决分布式系统当前主要的矛盾，同时对未来做出基本的预测，使得系统架构具备高并发、高可用、高可扩展性、高可维护性等非功能性需求，能够快速迭代，以适应不断变化的需求。
分布式系统架构的设计虽然比较复杂，但是也有一些业界遵循的原则。其中一些典型的架构原则来自The Art of Scalability一书，作者马丁L.阿伯特和迈克尔T.费舍尔分别是eBay和PayPal的CTO