使用SpringCloud解决微服务架构问题-第8章服务架构

第一篇的几章内容，从Java语言开始，讲解如何使用语言以及了解语言的特性；然后讲解了Maven工程的管理；接下来使用Git和Svn版本控制软件来管理代码；介绍了Linux系统命令，并且在Linux服务器中运行了一个Java程序。在第二篇的头几章内容中，学习了使用Spring框架治理来管理程序，并且了解了Spring MVC的页面编写等内容；上一章使用Spring Boot更简便地管理程序。其实到目前为止，已经可以通过讲解的内容编写自己的业务了。但是本书的范围明显不限于此。通过本章的了解，可以看到一个小系统是如何一步步变大的，以及系统变大后这种复杂系统的管理办法。

以一个电商系统为例，电商系统必须包含的模块有：用户、商品、订单订购关系、卖家及后台。这是最核心的几个模块，是初始搭建系统的时候，必须首先实现的。如果用Spring Boot实现这个基础系统，那么这些模块可能分属同一个工程的不同package，但是总体还是一个程序，程序外部连接数据库和一些静态的图片资源。这个系统可能会部署在一台服务器之内，当然了，如果这台服务器宕机了，那么电商平台也完蛋了。这个初始版的电商虽然不能保证稳定地提供业务，但是它确实具备了基础的功能业务能力，如图8-1所示。

这个系统的所有组件都部署在同一台服务器中，数据库和程序会共用CPU和内存，数据库和文件服务会共用磁盘，文件服务会和程序共用网络带宽。随着这个小电商系统慢慢开始有人访问，如果服务器性能不高的话，很容易形成性能瓶颈，此瓶颈是由硬件资源不足造成的。在此情况下，就需要根据硬件资源的具体情况，选择把一部分能力拆分出去，部署到另外一台服务器中，例如把数据库系统和静态资源拆分到其他服务器，那么现在就具备了3台服务器。如图8-2所示。

图8-1 单机服务器

图8-2 多台服务器

有一天，某台服务器宕机了，导致整个系统都瘫痪了，研发人员突然认识到单节点对业务造成了多大的风险。现在业务已经顺利开展了，不希望这种事情再次发生，于是决定把所有单节点的组件都变为双节点，这样即使其中一台瘫痪，系统还是能正常运行。这就涉及了反向代理和负载均衡，需要把系统压力合理分散到业务承载服务器上，如图8-3所示。

图8-3 带冗余的服务器集群

业务的发展越来越好，用户越来越多，服务的压力也越来越大，请求响应时间开始变长。经过诊断，发现几种情况，例如程序所在的应用服务器CPU使用率非常高，那么应该扩容应用服务器，提供更多的程序节点；例如发现数据库查询越来越慢，可能会对数据库进行分表或者读写分离，进行多写多读，或者使用分布式缓存^[31]和本地缓存，以降低数据库的压力；例如静态资源获取非常慢，可能会对静态资源配置CDN以提高速度，如图8-4所示。

(www.xing528.com)

图8-4 加入数据缓存等服务器集群

业务已经运行了很长时间了，工程中代码实现的业务逻辑也越来越多，越来越复杂。例如订单模块里会有打折，打折还要根据用户的等级设置折扣比例，用户等级的提高需要达到某个条件才行，这个条件的统计可能还在订单模块里，这些相关联的模块对研发和测试工作造成了很大的复杂度，可能修改一个小地方需要全系统的测试才能完成。为了降低程序内模块间的复杂度，可不可以把这些模块拆分为单独的服务？每个服务负责一部分能力，通过接口对外提供能力支持，各个服务之间也通过接口进行通信。当某个服务更新了，只要测试这个服务的接口能力就可以了，这样降低了全量集成测试的工作量，所以微服务的理念就诞生了。微服务是把一个大的程序拆分成一堆具备独立能力的程序集合，这种拆分会面临很多问题，例如服务间如何通信、使用什么协议、是不是长链接、服务间如何发现其他依赖服务、负载策略是什么、服务调用的链路如何跟踪、各个服务的压力如何监控、如此多的服务如何进行配置更新等。还好这些问题可以通过一个完善的微服务框架进行解决，例如Spring Cloud，如图8-5所示。

图8-5 微服务集群

现在系统中的服务已经拆分成了微服务体系，服务间的通信可能存在一些特殊情况，例如一些比较耗时或者实时性不高的业务，可能需要使用消息队列进行处理，有一些需要定时执行的任务可能需要分布式定时任务组件进行处理，还有日志体系也需要聚合起来进行跟踪，这样系统又会引入一系列功能组件，如图8-6所示。

图8-6 功能组件及微服务集群

现在系统已经非常庞大了，所有的程序是分模块的，并且每个模块都有很多个服务实例，甚至每个模块都有自己独立的数据库。每个服务使用了很多种业务组件，服务间的通信也需要RPC或消息队列，这对运维管理提出了很高的挑战，所以这个系统还需要添加持续集成和镜像等能力以辅助运维的工作，让系统可以实现自动化部署并且更加灵活。本书会涉及部分持续集成和镜像的内容，目的是让研发人员从运维角度理解服务集群的运行，如图8-7所示。

图8-7 运维体系、组件及微服务集群

通过以上这些操作，这个系统已经做得非常强大了，并且各个模块职责清晰，单独扩展能力强，持续集成可降低人工的工作量，镜像技术使系统更加灵活。此时，研发工程师可以非常轻松地在自己所负责的模块中进行开发工作而不用担心框架的问题；而架构师则可以通过框架治理等各个可视化界面来管控这么庞大的系统集群。