下面以淘宝架构为例，了解一下大型电商项目的服务器架构是什么样的，如图1所示：上面是一些Securitysystem体系，比如数据安全体系，应用安全体系系统、前端安全系统等。中间是业务运营服务系统，如会员服务、商品服务、店铺服务、交易服务等。还有共享服务，如分布式数据层、数据分析服务，配置服务，数据搜索服务等。最底层是中间件服务，比如MQS是队列服务，OCS是缓存服务等。图片来自于宝图。还有一些网络图中看不到的东西，比如高可用的体现，双机房容灾的实现，异地机房的单元化部署，提供稳定、高效、易维护的基础设施支持淘宝业务。图1这是一个含金量很高的架构，也是一个非常复杂和庞大的架构。当然，这个架构不是一天两天就进化出来的，也不是一上来就设计开发到这么高的水平。这里我想说的是，一个小公司应该如何架构呢？对于很多创业公司来说，前期很难预测十倍、一百倍、一千倍的流量后，网站结构会是什么样子。同时，如果在系统初期就设计出千万级并发流量的流量架构，任何公司都难以支撑这个成本。因此，一个大规模的服务体系是一步步来的。在每个阶段，找出该阶段网站架构面临的问题，然后不断解决这些问题。在这个过程中，整个架构会不断演进。1、单机-俗称allinone从一个小网站开始。一台服务器就够了。文件服务器、数据库、应用全部部署在一台机器上，俗称ALLINONE。随着我们的用户越来越多，访问量越来越大，硬盘、CPU、内存等都开始吃紧了，一台服务器已经满足不了了。这是我们看到下一个演变的地方。2、数据服务和应用服务分离3、缓存的使用包括本地缓存、远程缓存和远程分布式缓存。因为80%的业务访问都集中在20%的数据上，也就是我们常说的28法则，如果能把这部分数据缓存起来，性能立马提升。缓存分为两种：本地缓存和远程缓存，远程分布式缓存。这里的远程缓存图展示了一个分布式缓存集群（Cluster）。什么样的业务特征数据使用缓存？哪些业务特征数据使用本地缓存？哪些业务特征数据使用了远程缓存？分布式缓存在扩容时会遇到哪些问题？怎么解决？分布缓存算法有哪些类型？各自的优点和缺点是什么？第四，使用负载均衡实现服务器集群。加入负载均衡和服务器集群后，我们可以横向扩展服务器，解决服务器处理能力的瓶颈。负载均衡有哪些调度策略？各自的优点和缺点是什么？分别适用于哪些场景？比如我们有roundrobin、weight、addresshash，addresshash又分为originalipaddresshashhash、Targetipaddresshashhash、leastconnection、weightedleastconnection，还有很多继续升级的策略。。.让我们一一分析。典型负载均衡策略分析轮询：优点-实现简单，缺点-不考虑每台服务器的处理能力权重：优点-考虑服务器处理能力的不同地址散列：优点-可以实现同一个用户访问同一个服务器与leastnumberofconnections:优点-让集群中每台服务器的负载更加均匀Weightedleastconnections:在最少连接数的基础上给每台服务器增加一个权重。算法为（活跃连接数*256+非活跃连接数）/权重，计算出的值较小的服务器优先被选中。持续导致有问题的场景Sessionmanagement-SessionSticky这家餐厅吃饭还行。对于同一连接中的数据包，负载均衡器会将其转发到固定的后端服务器进行处理。它解决了我们session共享的问题，但是它的缺点是什么呢？某台服务器上运行的服务挂了或者重启了，上面的session都没有了。负载均衡器变成了有状态的机器，这给以后的容灾造成了障碍。SessionManagement-SessionCopy就好比我们在所有的餐厅都保留一份自己的餐具。如此一来，随意去任何一家餐厅就餐就OK了。不适合大型集群，适用于机器不多的情况。它解决了我们session共享的问题，但是它的缺点是什么呢？应用服务器之间的带宽问题，因为会话数据需要不断同步。大量用户在线时，服务器内存消耗过大。Session管理——基于Cookie比如我们每次去饭店吃饭，都是自带碗筷。它解决了我们session共享的问题，但是它的缺点是什么呢？cookie的长度限制。Cookies是保存在浏览器中的，安全性是个问题。SessionManagement-SessionServer比如我们的餐具就存放在一个巨大的柜子里。我们去任何一家餐厅吃饭，都可以从柜子里拿出自己的餐具。它解决了我们会话共享的问题。该方案需要考虑哪些问题？保证sessionserver的可用性，如何解决sessionserver的单点问题？我们需要在写应用的时候调整存储session的业务逻辑。比如，为了提高sessionserver的可用性，我们可以继续对sessionserver进行集群。五、中间总结那么当网站架构遇到一定的指标瓶颈和演进过程时，有哪些解决方案呢？它们的优点和缺点是什么？如何选择业务功能？如何做出选择？这个过程是最重要的。解决完应用服务器的横向扩展，我们继续回到现在的架构图：数据库的读写操作还是要经过数据库。当用户数量达到一定数量时，数据库就会成为瓶颈。如何解决？6、基于数据库读写分离的思考，如何支持多数据源？?每种ORM模型的优点和缺点是什么？如何选择？数据库读写分离会遇到以下问题：master和slave之间复制时，要考虑延迟问题，数据库支持，复制条件支持。当数据库为了提高可用性而划分到不同的机房，跨机房同步数据时，这就更成问题了。应用程序到数据源的路由问题。7、使用反向代理和CDN加速网站响应8、分布式文件系统思考点分布式文件系统如何做到不影响已经部署上线的业务访问？不能让某个图片突然无法访问。业务部门是否需要清洗数据？是否需要重做域名解析？这时候数据库又出现了瓶颈。九、数据垂直拆分，数据库为专用数据库，如图Products、Users、Deal数据库。解决写入数据时并发量大的问题。思考点如何解决跨业务交易？使用分布式事务，去掉事务或者不追求强事务。该应用程序有许多配置项。如何跨数据库连接数据？这时候某个业务数据表的数据量或者更新量已经达到了单个数据库的瓶颈。10、数据水平拆分如图所示，我们将User拆分为User1和User2，将同一张表的数据拆分到两个数据库中，解决了单个数据库的瓶颈。思考点横向拆分的策略有哪些？各自的优点和缺点是什么？水平拆分时如何清理数据？对于SQL路由，需要知道某个User在哪个数据库上。主键策略会有所不同。假设系统需要查询2017年4月下单的用户名详情，这些用户分布在user1和user2上，那么我们的后台操作系统是如何展示页面的呢？此时，公司已经将流量导入外部，我们应用程序中的搜索量猛增并不断发展。11.拆分搜索引擎总结本文只是一个示例演示。每个服务的技术架构都需要根据自己的业务特点进行优化演进，所以每个人的流程都不完全一样。最后一个例子并不完美。比如负载均衡还是单点，需要集群。我们的架构只是冰山一角。因为在架构演进的过程中，还必须考虑系统安全、数据分析、监控、反作弊等。同时，为了以后的发展，SOA架构、面向服务、消息队列、任务调度、多机房等也要考虑。从上面对架构演进的解释也可以看出，所有大型项目的架构和代码都是根据实际业务场景和开发条件一步步开发演进的。在不同的阶段，将使用不同的技术。不同的架构用于解决实际问题。因此，高层次的项目技术架构和开发设计的落地，不是一蹴而就的。正所谓拔地而起。在架构演进的过程中，从核心模块代码到核心架构，都会不断演进。这个过程值得我们深入研究和思考。
