架构师训练营第四周总结

这一周的学习，老师带领我们学习了一个简单的系统是如何一步步演进为一个大型复杂的互联网系统的全过程。



最简单的互联网系统，尤其是交易类的系统至少需要的组件或模块有：数据库服务、Web应用服务、文件存储服务，最初这些服务甚至可以部署在同一台物理机上。



随着系统的演进，把应用服务和数据库分离，各自部署在不同的服务器之上，当访问量增大，系统响应时间变大，会使用本地缓存来降低读取数据的读压力，但是单台机器的内存有限，就又演化为使用多台缓存服务器的分布式缓存。



接下来，随着业务量的增长，应用服务器的处理能力成为瓶颈，这时候就面临着两个选择：花费重金购买性能更强的小型机来做垂直扩展，或采用多台更低廉普通服务器进行水平扩展。垂直扩展简单，系统不需要做任何改造，水平扩展需要对系统进行改造以支持分布式调用。初期建议采用垂直扩展的方式，直到遇到垂直扩展的性价比的拐点。对于采用分布式的水平扩展方式，需要增加一个前置的负载均衡以路由外部请求。



与此同时，为了进一步减低数据库的负载，采用读写分离的方式多部署一台数据库服务器，主数据库负责写，从数据库负责读。



随着互联网访问流量越来越大，展示内容越来越丰富，更多的数据流量都是静态类资源：比如图片，静态页面等，真正到达应用服务器需要进行计算的流量非常小，所以把静态类资源分离到单独的服务器和带宽并且距离用户地理位置更近的服务器上，可以购买云服务厂商的对象存储，经过简单配置即可同时使用CDN功能了。



再随着业务进一步发展，数据库存储的数据超过百万千万，就需要通过分片利用多台数据库服务器来分布式存储数据，分片在降低数据库单库访问压力的同时，也会大大降低数据库的查询能力，即便是简单的查询也变得很复杂，比较常见的是将历史数据分片到单独的服务器。



随着业务发展，需求越来越多样性，关系型数据库更有优势的是解决核心的交易数据持久化问题，非交易的例如查询需求可以采用NoSQL或搜索引擎来解决。



最后，随着系统变得越来越庞大，开发人员越来越多，开发和维护变得越来越困难，这时候就需要根据产品线把业务进行拆分，形成多个不同的子系统，分别由不同的产品线团队负责，每个产品线都拥有完整的职能角色和技术栈，到此系统演化为微服务架构，通用的业务服务形成中台。