浓缩精华的架构演进过程，经验总结，值得收藏！

架构设计的演进过程

业务驱动技术的发展是亘古不变的道理。最开始的时候，业务量少，业务复杂度低，采起的技术也相对简单，基本知足用户对功能的需求。随着IT信息化的普及，更多的交易放到了网络上，信息量增长和访问次数频繁就是要解决的问题了。所以，逐渐加入了缓存、集群等技术手段。同时对业务的扩展性和伸缩性的要求也愈来愈高。高并发、高可用、可伸缩、可扩展、够安全的软件架构一直是架构设计追求的目标。今天咱们来看一下架构设计经历了哪些阶段，每一个阶段都解决了哪些问题，又引出了哪些新问题。主要是引发你们的思考，在不一样的业务发展阶段采起合适技术手段，用变化拥抱变化是IT人追求的目标。

应用与数据一体模式

最先的业务应用以网站、OA等为主，访问的人数有限，单台服务器就可以应付。一般，将应用程序和数据库部署到一台服务器上面，如图1-1所示。在这一阶段，咱们利用LAMP（Linux Apache MySQL PHP）技术就能够迅速搞定，而且这些工具都是开源的。很长一段时间内，有各类针对这种应用模式的开源代码可使用。这种模式基本上没有高并发的要求，可用性也不好。有的服务器采用托管模式，上面就安装了不一样的业务应用，一旦服务器出现问题，全部的应用就罢工了。不过其开发和部署成本相对较低，适合刚刚起步的应用服务。图1 就描述了单个应用和数据库运行在单台服务器的模式，咱们称这种模式为应用与数据一体模式。

图 1 应用与数据一体模式

应用与数据分离模式

随着业务的发展，用户数和请求数逐渐上升，服务器的性能出现了问题。其中比较简单的解决方案就是增长资源，将业务应用和数据存储分开，其架构图如图2所示。其中，应用服务器须要处理大量的业务请求，对CPU和内存有必定要求；而数据库服务器须要对数据进行存储和索引等IO操做，对磁盘的转速和内存会考虑更多。这样的分离解决了性能的问题，咱们须要扩展更多的硬件资源让其各司其职，使系统能够处理更多的用户请求。虽然业务上依旧存在耦和，但硬件层面的分离在可用性上比一体式设计要好不少。

图2 应用与数据分离模式

缓存的加入

随着信息化系统的发展和使用互联网人数的增多，业务量、用户量、数据量都在增加。咱们同时发现，用户会对某些数据的请求量特别大，例如新闻、商品信息和热门消息。以前这些信息的获取方式是依靠数据库，所以受到数据库IO性能的影响。此时数据库成为了整个系统的瓶颈。若是再增长服务器的数量，恐怕也很难解决，因而缓存技术就登场了，其架构图如图3所示。这里提到的缓存技术分为客户端浏览器缓存、应用服务器本地缓存和缓存服务器缓存。

• 客户端浏览器缓存：当用户经过浏览器请求服务器的时候，会发起HTTP请求。若是对每次HTTP请求进行缓存，那么能够减小应用服务器的压力。
• 应用服务器本地缓存：它使用的是进程内缓存，又叫托管堆缓存。以Java为例，这部分缓存放在JVM的托管堆上面，同时会受到托管堆回收算法的影响。因为它运行在内存中，对数据的响应速度很快，一般咱们会把热点数据放在这里。在进程内缓存没有命中的时候，会到缓存服务器中获取信息，若是仍是没有命中，才会去数据库中获取。
• 缓存服务器缓存：它相对于应用服务器本地缓存来讲，就是进程外缓存，既能够和应用服务部署在同一服务器，也能够部署到不一样的服务器。通常来讲，为了方便管理和合理利用资源，会将其部署到专门的缓存服务器上面。因为缓存会占用内存空间，所以这类服务器会配置比较大的内存。
  图3 描述了缓存请求的次序，先访问客户端缓存，以后是进程内的本地缓存，接下来是缓存服务器，最后才是数据。若是在任意一层获取了缓存信息，就再也不往下访问了，不然会一直按照这个次序获取缓存信息，直到数据库。
  
  图3 缓存的加入
  用户请求访问数据的顺序为客户端浏览器缓存→应用服务器本地缓存→缓存服务器缓存。若是按照以上次序尚未命中数据，才会访问数据库获取数据。
  加入缓存的设计，提升了系统的性能。因为缓存放在内存中，而内存的读取速度比磁盘要快得多，可以很快响应用户请求。特别针对一些热点数据，优点尤其明显。同时，在可用性方面也有明显的改善。即便数据库服务器出现短期的故障，缓存服务器中保存的热点或者核心数据依旧能够知足用户暂时的访问。固然，后面还会对可用性进行优化。

  服务器集群的加入

  通过前面三个阶段的演进，系统对用户的请求量有了很好的支持。实际上，这都是在解决高性能和可用性的问题，这一核心问题会一直贯穿整个系统架构的演进过程当中。随着用户请求量的增长，另一个问题又出现了，那就是并发。把这两个字拆开了来看：并，理解为“一块儿并行“，有同时的意思；发，理解为“发出调用”，也就是请求的意思。合起来就是多个用户同时请求应用服务器。若是说原来的系统面对的仅仅只是大数据量的话，那么如今就须要面对多用户同时请求。若是仍是按照上一个阶段的架构图推导，单个应用服务器已经没法知足高并发的要求了。此时，服务器集群就加入战场了，其架构图如图4所示。服务器集群也就是多台服务器扎堆的意思，用更多的服务器来分担单台服务器的负载压力，提升性能和可用性。再说白一点，就是提升单位时间内服务处理请求的数量。原来是一个服务器处理，如今是一堆服务器来处理。就好像银行柜台同样，增长柜员的人数来服务更多的人。
  
  图4服务器集群的加入
  此次架构演进与上次相比，增长了应用服务器的个数，用多台应用服务器造成集群。应用服务器中所部署的应用服务没有改变，在用户请求与服务器之间加入了负载均衡器，帮助用户请求路由到对应的服务器中。增长服务器的举动代表，系统的瓶颈是在处理用户并发请求上。针对数据库和缓存都没有作更改，这样仅仅经过增长服务器数量就可以缓解请求的压力。服务器集群会经过多台服务器来分担原来一台服务器须要处理的请求，在多台服务器上同时运行一套系统，所以能够同时处理大量并发的用户请求。有点三个臭皮匠顶个诸葛亮的意思，所以对集群中单个服务器的硬件要求也会下降。此时须要注意负载均衡均衡的算法，例如轮询和加权轮询。咱们要保证用户请求可以均匀分布到服务器上面，同一个会话的请求保证在同一个服务器上面处理，针对不一样服务器资源的优劣动态调整流量。负载均衡器加入以后，因为其位于互联网与应用服务器之间，负责用户流量的接入，所以能够对用户流量进行监控，同时对访问用户的身份和权限进行验证。

  数据库读写分离

  加入缓存能够解决部分热点数据的读取，但缓存数据的容量有限，那些非热点的数据依旧会从数据库中读取。数据库对于写入和读取的性能是不同的。在写入数据的时候，会形成锁行或者锁表，此时若是有其余写入操做并发执行，会存在排队现象。而读取操做比写入操做更加快捷，而且能够经过索引、数据库缓存等方式实现。所以，推出了数据库读写分离的方案，其架构图如图5所示。此时设置了主从数据库，主库（master）主要用来写入数据，而后经过同步binlog的方式，将更新的数据同步到从库（slave）中。对于应用服务器而言，在写数据的时候只须要访问主库，在读数据的时候只用访问从库就行了。
  
  图5 数据库读写分离
  利用数据库读写分离的方式，将数据库的读/写职责分离。利用读数据效率较高的优点，扩展更多的从库，从而服务于读取操做的用户请求。毕竟在现实场景中，大多数操做都是读取操做。此外，从数据同步技术的角度来讲，又能够分为同步复制技术、异步复制技术和半同步复制技术。在数据库读写分离带来益处的同时，架构也须要考虑可靠性的问题。例如，主库若是挂掉，从库如何接替主库进行工做。主库在恢复之后，是成为从库仍是继续担当主库，以及如何同步数据的问题。

  反向代理与CDN

  随着互联网的逐渐普及，人们对网络安全和用户体验的要求也愈来愈高。以前用户都是经过客户端直接访问应用服务器获取服务，应用服务器会暴露在互联网中，容易遭到***。若是在应用服务器与互联网之间加上一个反向代理服务器，它接收用户的请求，而后再转发到内网的应用服务器，充当外网与内网之间的缓冲。反向代理服务器只是作请求的转发，在它上面没有运行任何应用，所以当有人***它的时候，是不会影响到内网的应用服务器的。这无形中保护了应用服务器，提升了安全性。同时，它也在互联网与内网之间起到适配和网速转换的做用。例如，应用服务器须要服务公网和教育网，可是两个网络的网速不一样，能够在应用服务器与互联网之间放上两台反向代理服务器，一台链接公网，另外一台链接教育网，屏蔽网络差别，服务于更多的用户群体。如图6 公网客户端和校园网客户端分别来自公网与校园网两个不一样的网络，因为两个网络访问速度不一样，所以会针对两个网络分别设置共网代理服务器和校园网代理服务器，经过这种方式将位于不通网络的用户请求接入到系统中。
  
  图6加入反向代理服务器
  聊完反向代理，再来讲说CDN，它的全称是Content Delivery Network，也就是内容分发网络。若是把互联网想象成一张大网的话，每一个服务器或者客户端就是分布式在网中的一个节点。节点之间的距离有远有近，用户请求会从一个节点跳转到另一个节点，最终跳转到应用服务器获取信息。若是跳转的次数越少，就可以更快地获取信息，所以能够在离客户端近的节点存放信息。这样用户经过客户端，只须要较少的跳转次数就可以触达信息。因为这部分信息更新频率不高，推荐存放一些静态数据，例如JavaScript文件、静态的HTML、图片文件等。这样客户端就能够从离本身最近的网络节点获取资源，大大提升了用户体验和传输效率。加入CDN后的架构图如图7所示。
  
  图7 加入CDN
  CDN的加入明显加快了用户访问应用服务器的速度，同时也减轻了应用服务器的压力，原来必须直接访问应用服务器的请求，不用通过层层网络，而只用找到最近的网络节点就能够获取资源。但从请求资源的角度上来看，这种方式也有局限性，它只能对静态资源起做用，须要定时对CDN服务器进行资源更新。反向代理和CDN的加入解决了安全性、可用性和高性能的问题。

  分布式数据库与分表分库

  经历前面几个阶段之后，软件的系统架构相对趋于稳定。随着系统运行时间的增长，数据库中累积的数据愈来愈多，同时系统还会记录一些过程数据，例如操做数据和日志数据，这些数据也会加剧数据库的负担。即使数据库设置了索引和缓存，但在海量数据查询的时候还会捉襟见肘。若是说读写分离，是将数据库从读写层面进行资源分配，那么分布式数据库就须要从业务和数据层面对资源进行分配。

• 对于数据表来讲，当表中包含的记录过多时，会将其分红多张表来存储。例如：有1000万个会员记录，就能够将其分红两个500万，分别放到两个表中存储。也能够按照业务将表中的列进行分割，把表中的某些列放到其余表中存储，而后经过外键关联到主表，被分割出去的列一般是不常常访问的数据。
• 对于数据库来讲，每一个数据库可以承受的最大链接数和链接池是有上限的。为了提升数据访问效率，会根据业务需求对数据库进行分割，让不一样的业务访问不一样的数据库。固然，也能够将相同业务的不一样数据放到不一样的库中存储。
  若是将这些数据库资源分别放到不一样的数据库服务器中，就是分布式数据库设计了。因为数据存储在不一样的表/库中，甚至在不一样的服务器上面，在进行数据库操做的时候会增长代码的复杂度。此时能够加入数据库中间件来消除这些差别。架构如图8所示，将数据拆分之后分别放在表1和表2 中，两张表所在的数据库服务器也各不相同，库与库之间还须要考虑数据同步的问题。因为数据的分散部署，要从业务应用获取数据就须要依靠数据库中间件帮忙。
  
  图8 分布式数据库与分表分库
  数据库的分表分库以及分布式设计，会带来性能的提高，同时也增大了数据库管理和访问的难度。原来只用访问一张表和一个库，如今须要跨越多张表和多个库。
  从软件编程的角度来看，有一些数据库中间件提供了最佳实践，例如MyCat和Sharding JDBC。此外，从数据库服务器管理的角度来看，须要监控服务器的可用性。从数据治理的角度来看，须要考虑数据扩容和数据治理的问题。

  业务拆分

  当解决大数据量存储问题之后，系统就可以存储更多的数据，这意味着可以处理更多的业务。业务量的增长，访问数的上升，是任何一个软件系统在任什么时候期都要面临的严峻考验。经过前面几个阶段的学习，咱们知道系统提高基本依靠空间换取时间，使用更多的资源和空间处理更多的用户请求。随着业务的复杂度愈来愈高，以及高并发的来临，一些大厂开始将业务系统进行切分，分开部署，此时的架构图如图10所示。若是说前面的服务器集群模式是将同一个应用复制到不一样的服务器上，那么业务拆分就是将一个应用拆成多个部署到不一样的服务器中。此外，还能够对核心应用进行水平扩展，将其部署到多台服务器上。应用虽然作了拆分，但应用之间仍旧有关联，存在应用之间的调用、通讯和协调问题。由此也会引入队列、服务注册发现、消息中心等中间件，它们能够协助系统管理分布到不一样服务器、网络节点上的应用。
  
  图9业务拆分
  业务拆分之后会造成一个个应用服务，既有基于业务的服务，例如商品服务、订单服务，也有基础服务，例如消息推送和权限验证。这些应用服务连同数据库服务器分布在不一样的容器、服务器、网络节点中，对它们的通讯、协调、管理和监控都是咱们须要解决的问题。

  分布式与微服务

  近几年，微服务是比较火的架构方式，它将业务应用进行更加精细化的切割，使之成为更加小的业务模块。作到模块的高内聚低耦合，每一个模块能够独立存在，由独立的团队维护。每一个模块内部能够采起特有的技术，而不用关心其余模块的技术实现。模块经过容器的部署运行，模块之间经过接口和协议进行调用。任何一个模块均可以将本身公开给其余的模块调用。同时能够将热点模块进行水平扩展，加强系统的性能。当其中某一个模块出现问题时，又能够由其余相同的模块代替其工做，加强了可用性。
  大体总结下来，微服务拥有如下特色，业务精细化拆分、自治性、技术异构性、高性能、高可用。它像极了分布式架构，下面来看看它们的区别，如图10所示。
  从概念上理解，它们都作了“拆”的动做，但在下面这几个方面存在区别。

• 拆分目的不一样：分布式设计是为了解决单体应用资源有限的问题，在一个服务器上没法支撑更高的用户访问，所以将一个应用拆解成不一样的部分，而后将其部署到不一样服务器上，从而分担高并发的压力。微服务是对服务组件进行精细化，目的是更好地解耦，让服务之间经过组合完成高性能、高可用、可伸缩、可扩展。
• 拆分方式不一样：分布式服务架构将系统按照业务和技术分类进行拆分，目的是让拆分的服务负载原来单一服务的业务。微服务则是在分布式的基础上进行更细的拆分，它将服务拆成更小的模块，更加专业化，分工更加精细，而且每一个小模块均可以独立运行。
• 部署方式不一样：分布式将服务拆分之后，一般会部署到不一样的服务器上。而微服务也能够将不一样的服务模块放到不一样的服务器上，同时它也能够在一个服务器上部署多个微服务，或者同一个微服务的多个备份，而且多使用容器的方式部署。
  
  图10 分布式与微服务的区别
  虽然分布式与微服务有以上区别，但从实践的角度来看，它们都是基于分布式架构的思想构建的。微服务是分布式的进化版本，也是分布式的子集。它一样会遇到服务拆分、服务通讯、协同、管理调度等问题。

  总结

  本文按照技术跟随业务变化的思路，描述从单体架构到集群，再到分布式架构以及微服务的发展阶段。讲述了每一个软件架构阶段变化的特色，先后架构更替的缘由和关系，说明了软件架构发展会一直随着业务发展的方向变化。遵循高性能，高可用，伸缩性，扩展性，安全性的架构目的。