大型项目架构演进过程及思考

淘宝架构

咱们以淘宝架构为例，了解下大型的电商项目的服务端的架构是怎样，如图所示

上面是一些安全体系系统，如数据安全体系、应用安全体系、前端安全体系等。
中间是业务运营服务系统，如会员服务、商品服务、店铺服务、交易服务等。
还有共享业务，如分布式数据层、数据分析服务、配置服务、数据搜索服务等。
最下面呢，是中间件服务，如MQS即队列服务，OCS即缓存服务等。

图中也有一些看不到，例如高可用的一个体现，实现双机房容灾和异地机房单元化部署，为淘宝业务提供稳定、高效和易于维护的基础架构支撑。

这是一个含金量很是高的架构，也是一个很是复杂而庞大的架构。固然这个也不是一天两天演进成这样的，也不是一上来就设计并开发成这样高大上的架构的。

这边就要说一下，小型公司要怎么作呢？对不少创业公司而言，很难在初期就预估到流量十倍、百倍以及千倍之后网站架构会是什么样的一个情况。同时，若是系统初期就设计一个千万级并发的流量架构，很难有公司能够支撑这个成本。

所以，一个大型服务系统都是从小一步一步走过来的，在每一个阶段，找到对应该阶段网站架构所面临的问题，而后在不断解决这些问题，在这个过程当中整个架构会一直演进。
那咱们来一块儿看一下。

单服务器-俗称all in one

从一个小网站提及。一台服务器也就足够了。文件服务器，数据库，还有应用都部署在一台机器，俗称ALL IN ONE

随着咱们用户愈来愈多，访问愈来愈大，硬盘，CPU，内存等都开始吃紧。一台服务器已经知足不了。这个时候看一下下一步演进

数据服务与应用服务分离

 

 

 

咱们将数据服务和应用服务分离，给应用服务器配置更好的 CPU，内存。而给数据服务器配置更好更大的硬盘。

分离以后提升必定的可用性，例如Files Server挂了，咱们仍是能够操做应用和数据库等。
随着访问qps愈来愈高，下降接口访问时间，提升服务性能和并发，成为了咱们下一个目标，发现有不少业务数据不须要每次都从数据库获取。

使用缓存，包括本地缓存，远程缓存，远程分布式缓存

 

 

 

由于 80% 的业务访问都集中在 20% 的数据上，也就是咱们常常说的28法则。若是咱们能将这部分数据缓存下来，性能一会儿就上来了。而缓存又分为两种：本地缓存和远程缓存缓存，以及远程分布式缓存，咱们这里面的远程缓存图上画的是分布式的缓存集群(Cluster)。

思考的点

1. .          具备哪一种业务特色数据使用缓存？
2. .          具备哪一种业务特色的数据使用本地缓存？
3. .          具备哪一种务特色的数据使用远程缓存？
4. .          分布式缓存在扩容时候会碰到什么问题？如何解决？分布式缓存的算法都有哪几种？各有什么优缺点？

这个时候随着访问qps的提升，服务器的处理能力会成为瓶颈。虽然是能够经过购买更强大的硬件，但总会有上限，并且这个到后期成本就是指数级增加了，这时，咱们就须要服务器的集群。须要使咱们的服务器能够横向扩展，这时，就必须加个新东西：负载均衡调度服务器。

使用负载均衡，进行服务器集群

 

 

增长了负载均衡，服务器集群以后，咱们能够横向扩展服务器，解决了服务器处理能力的瓶颈。

思考的点

1. .          负载均衡的调度策略都有哪些？
2. .          各有什么优缺点？
3. .          各适合什么场景？

打个比方，咱们有轮询，权重，地址散列，地址散列又分为原ip地址散列hash，目标ip地址散列hash，最少链接，加权最少链接，还有继续升级的不少种策略......咱们一块儿来分析一下

典型负载均衡策略分析

1. .          轮询：优势：实现简单，缺点：不考虑每台服务器处理能力
2. .          权重：优势：考虑了服务器处理能力的不一样
3. .          地址散列：优势：能实现同一个用户访问同一个服务器
4. .          最少链接：优势：使集群中各个服务器负载更加均匀
5. .          加权最少链接：在最少链接的基础上，为每台服务器加上权值。算法为(活动链接数*256+非活动链接数)/权重，计算出来的值小的服务器优先被选择。

继续引出问题的场景：

咱们的登陆的时候登陆了A服务器，session信息存储到A服务器上了，假设咱们使用的负载均衡策略是ip hash，那么登陆信息还能够从A服务器上访问，可是这个有可能形成某些服务器压力过大，某些服务器又没有什么压力，这个时候压力过大的机器(包括网卡带宽)有可能成为瓶颈，而且请求不够分散。

这时候咱们使用轮询或者最小链接负载均衡策略，就致使了，第一次访问A服务器，第二次可能访问到B服务器，这个时候存储在A服务器上的session信息在B服务器上读取不到。

Session管理-Session Sticky粘滞会话：

 

 

 

打个比方就是若是咱们每次吃饭都要保证咱们用的是本身的碗筷，而只要咱们在一家饭店里存着咱们的碗筷，只要咱们每次去这家饭店吃饭就行了。

对于同一个链接中的数据包，负载均衡会将其转发至后端固定的服务器进行处理。

解决了咱们session共享的问题，可是它有什么缺点呢？

1. .          一台服务器运行的服务挂掉，或者重启，上面的 session 都没了
2. .          负载均衡器成了有状态的机器，为之后实现容灾形成了羁绊

Session管理-Session 复制

 

就像咱们在全部的饭店里都存一份本身的碗筷。咱们随意去哪一家饭店吃饭都OK，不适合作大规模集群，适合机器很少的状况。

解决了咱们session共享的问题，可是它有什么缺点呢？

1. .          应用服务器间带宽问题，由于须要不断同步session数据
2. .          大量用户在线时，服务器占用内存过多

Session管理-基于Cookie

 

 

 

打个比方，就是咱们每次去饭店吃饭，都本身带着本身的碗筷。

解决了咱们session共享的问题，可是它有什么缺点呢？

1. .          cookie 的长度限制
2. .          cookie存于浏览器，安全性是一个问题

Session管理-Session 服务器

 

 

 

打个比方，就是咱们的碗筷都存在了一个庞大的橱柜里，咱们去任何一家饭店吃饭，均可以从橱柜中拿到属于咱们本身的碗筷。

解决了咱们session共享的问题，这种方案须要思考哪些问题呢？

1. .          保证 session 服务器的可用性，session服务器单点如何解决？
2. .          咱们在写应用时须要作调整存储session的业务逻辑

打个比方，咱们为了提升session server的可用性，能够继续给session server作集群

中间总结

因此说，网站架构在遇到某些指标瓶颈时，演进的过程当中，都有哪些解决方案，他们都有什么优缺点？业务功能上如何取舍？如何作出选择？这个过程才是最重要的。

在解决了横向扩展应用服务器以后，那咱们继续~~

继续回到目前架构图

 

 

 

数据库的读及写操做都还须要通过数据库。当用户量达到必定量，数据库将会成为瓶颈。那咱们如何来解决呢？

数据库读写分离

 

 

 

使用数据库提供的热备功能，将全部的读操做引入slave 服务器，由于数据库的读写分离了，因此，咱们的应用程序也得作相应的变化。咱们实现一个数据访问模块(图中的data access module)使上层写代码的人不知道读写分离的存在。这样多数据源读写分离就对业务代码没有了侵入。这里就引出了代码层次的演变

思考的点

1. .          如何支持多数据源？
2. .          如何封装对业务没有侵入？
3. .          如何使用目前业务的ORM框架完成主从读写分离？是否须要更换ORM模型？ORM模型之间各有什么优缺点？
4. .          如何取舍？

数据库读写分离会遇到以下问题：

1. .          在master和slave复制的时候，考虑延时问题、数据库的支持、复制条件的支持。
2. .          当为了提升可用性，将数据库分机房后，跨机房传输同步数据，这个更是问题。
3. .          应用对于数据源的路由问题

使用反向代理和 CDN 加速网站响应

 

 

 

使用 CDN 能够很好的解决不一样的地区的访问速度问题，反向代理则在服务器机房中缓存用户资源。

访问量愈来愈大，咱们文件服务器也出现了瓶颈。

分布式文件系统

 

 

 

思考的点

1. .          分布式文件系统如何不影响已部署在线上的业务访问？不能让某个图片忽然访问不到呀
2. .          是否须要业务部门清洗数据？
3. .          是否须要从新作域名解析？

这个时候数据库又出现了瓶颈

数据垂直拆分

 

 

 

数据库专库专用，如图Products、Users、Deal库。

解决写数据时，并发，量大的问题。

思考的点

1. .          跨业务的事务？如何解决？使用分布式事务、去掉事务或不追求强事务
2. .          应用的配置项多了
3. .          如何跨库进行数据的join操做

这个时候，某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈

数据水平拆分

 

 

 

如图，咱们把User拆成了User1和User2，将同一个表的数据拆分到两个数据库中，解决了单数据库的瓶颈。

思考的点

1. .          水平拆分的策略都有哪些？各有什么优缺点？
2. .          水平拆分的时候如何清洗数据？
3. .          SQL 的路由问题，须要知道某个 User 在哪一个数据库上。
4. .          主键的策略会有不一样。
5. .          假设咱们系统中须要查询2017年4月份已经下单过的用户名的明细，而这些用户分布在user1和user2上，咱们后台运营系统在展现时如何分页？

这个时候，公司对外部作了流量导入，咱们应用中的搜索量飙升，继续演进

拆分搜索引擎

 

 

 

使用搜索引擎，解决数据查询问题。部分场景可以使用 NoSQL 提升性能，开发数据统一访问模块，解决上层应用开发的数据源问题。如图data access module 能够访问数据库，搜索引擎，NoSQL

最后总结

这个只是一个举例演示，各个服务的技术架构是须要根据本身业务特色进行优化和演进的，因此你们的过程也不彻底相同。

最后的这个也不是完美的，例如负载均衡仍是一个单点，也须要集群，咱们的这个架构呢也只是冰山一角，沧海一粟。在架构演进的过程当中，还要考虑系统的安全性、数据分析、监控、反做弊等等......，同时继续发展呢，SOA架构、服务化、消息队列、任务调度、多机房等等… ...

从刚才对架构演进的讲解，也能够看出来，全部大型项目的架构和代码，都是这么一步一步的根据实际的业务场景，和发展状况发展演变而来的，在不一样的阶段，会使用的不一样的技术，不一样的架构来解决实际的问题，因此说，高大上的项目技术架构和开发设计实现不是一蹴而就的。

正是所谓的万丈高楼平地起。在架构演进的过程当中，小到核心模块代码，大到核心架构，都会不断演进的，这个过程值得咱们去深刻学习和思考。