作者：陈韶健
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
SpringCloud与Docker高并发微服务架构设计实施试读：
前言
简单地说，微服务就是一种使用轻量级架构设计的组件化的小应用，这种小应用只关注一定范围的业务功能，往往只负责做好一件事情。通过很多这样的小应用，利用一种高效而灵活的管理机制，可以组成一个功能全面且业务丰富的大型平台。这种管理机制包括服务的注册与发现、服务的路由与负载均衡管理、服务之间简单而快捷的通信等功能。
轻量级的微服务架构设计方法，是在竞争激烈的互联网环境中诞生并且发展起来的，非常适合互联网应用快速迭代和规模化扩张的特点。当风靡一时的SOA架构因为其重量级的设计方法，并不能适应业务快速变更和高速发展的要求时，微服务架构轻量级的设计风格的出现无疑是软件工程设计的救星，它给软件工程设计重新注入了一股新鲜活跃的血液。
互联网经济激烈竞争的特性，致使业务需求经常发生变化，这就要求技术开发必须具有非常快速的响应能力，以快速抢占市场先机，体现一种“高手过招、唯快不破”的风格。而且，产品一经推出，必须经常进行调整和迭代，以使其始终都能处于“出类拔萃、鹤立鸡群”的地位。更为重要的一面是互联网经济巨大的市场潜力，必然会触发应用产品走上规模化扩张的道路，这种扩张有时甚至是爆炸性的，这对产品的性能和稳定性都提出了前所未有的高要求。
对于软件设计和开发，唯有轻装上阵才能时刻充满活力，始终具有冲锋陷阵的干劲和强壮的生命力。微服务架构轻量级的设计观念及其渐进式的开发特点，正是体现了这种与时俱进的先进设计思想。
在微服务架构设计实施的实践中，Netflix OSS是大家所公认的最早使用微服务架构设计的典范，Spring团队在其开源组件的基础上，组建了一个基于Spring Boot 开发框架的Spring Cloud工具套件。Spring Cloud工具套件为开发者提供了一个完整而配套的工具组件，使微服务架构的实施和开发变得更加普通和容易。Spring Cloud工具套件提供了包括但不限于服务注册管理、智能路由、负载均衡服务、熔断容错和服务降级机制、集中配置管理、服务监控与跟踪等功能组件和服务。
本书将详细介绍如何使用Spring Cloud工具套件来设计和开发微服务，并且不只是停留在表面上对Spring Cloud各个工具组件本身的使用说明和介绍，而是从架构设计出发，说明了如何更好地将微服务架构的设计理念应用于生产实践中，并在实际应用中加深对Spring Cloud工具套件的理解和掌握的程度。同时还将介绍怎么使用Docker和Jenkins等工具来进行微服务的部署和发布，并通过构建一系列高可用性的服务器架构设计，阐述了构建一个稳定、可靠并且能够适应规模化发展的应用平台的方法。
本书将从架构设计、应用开发和运维部署三个方面出发，对微服务架构设计的实施进行全方位的介绍和详细说明，在这一过程中将使用一个互联网平台的实例展开分析和深入实践。
通过对本书的系统学习，可以让读者将微服务架构的设计方法快速应用于生产实践中，为开发团队和企业提供坚不可摧的竞争力。
让我们一起努力，共同探索吧！让先进的技术率先成为我们先进的生产力。
本书的读者对象
本书的读者对象为广大的Java开发者、系统架构师和系统运维人员。本书特别适合使用过Spring开源框架或具有Spring框架基础知识的广大用户群体。
本书章节组成
本书由三部分组成，各部分及其章节的结构如下所示。
第一部分 架构篇
第1章 微服务架构与Spring Cloud
第2章 微服务架构最佳设计
第3章 电商平台微服务设计实例
第二部分 开发篇
第4章 开发工具选用及Spring Boot基础
第5章 电商平台微服务工程设计
第6章 微服务治理基础服务开发
第7章 Rest API微服务开发
第8章 Web UI微服务开发
第9章 电商平台移动商城开发
第10章 商家管理后台与SSO设计
第11章 平台管理后台开发
第三部分 运维篇
第12章 服务器架构设计与Docker使用
第13章 数据库集群设计与高可用读写分离实施
第14章 分布式文件系统等基础设施安装与配置
第15章 使用自动化构建工具Jenkins实现CI/CD
实例代码
本书的实例代码存放在开源中国的码云代码仓库之中，可以通过下列链接打开各个项目工程下载或使用Git检出：
https://gitee.com/chenshaojian/projects
勘误与反馈
读者如有任何问题，可以通过如下链接发起话题与作者交流。本书在出版印刷之后，有需要勘误的地方也会首先在这里发布：
https://gitee.com/chenshaojian/SpringCloud/issues
致谢
非常感谢长期给予我支持和鼓励的朋友们，因为有了你们的支持和鼓励，才让我感到无比的幸福和惬意。还要感谢曾经与我一起进行过微服务开发的小伙伴们，令人欣慰的是，我已经兑现了之前的承诺，将微服务架构设计的经验汇编成书。最后要感谢家人对我的支持，在本书写作的过程中，我几乎将所有的空闲时间都花费在写作之中，而忽略了对你们的陪伴，对此我深感歉意。
如果书中有不对的地方或者任何纰漏，还敬请大家不吝赐教，我将感激不尽。第一部分架构篇第1章 微服务架构与Spring Cloud第2章 微服务架构最佳设计第3章 电商平台微服务设计实例这一部分阐述了微服务架构的设计观念及其发展情况，同时介绍了Spring Cloud工具套件中各个组件的功能，并说明如何以Spring Cloud工具套件为基础，在微服务架构设计中进行权衡与提炼，构建微服务架构的最佳设计，同时通过一个电商平台的设计实例实现了这种最佳设计。1微服务架构与Spring Cloud
近几年，大家都在谈论微服务，微服务是一个非常火爆的关键词，在百度中搜索微服务，随便就有几千万条结果。那么，什么是微服务呢，微服务的概念是怎么产生的呢？
相信大家对微服务也不陌生，或者正在做着相关的开发，现在，我们先来了解一下微服务架构的来龙去脉，为什么要使用微服务架构，微服务架构能给我们带来什么好处，微服务架构与Spring Cloud又是一种什么关系。1.1 微服务概念的由来
据说，早在2011年5月，在威尼斯附近的一个软件架构师研讨会上，就有人提出了微服务架构设计的概念，用它来描述与会者所看得见的一种通用的架构设计风格。时隔一年之后，在同一个研讨会上，大家决定将这种架构设计风格用微服务架构来表示。
起初，对微服务的概念，也没有一个明确的定义，大家只能从各自的角度说出了对微服务的理解和看法。
有人把微服务理解为一种细粒度的SOA（Service-Oriented Architecture，面向服务架构），一种轻量的组件化的小型SOA。
有人把微服务看作一种使用HTTP通信的自包含的轻量进程。
……
在这些看法中，比较统一的一点就是，大家都认为微服务是一种小型的应用程序，并且使用轻量级的设计方法和轻量级的HTTP通信。
在2014年3月，詹姆斯·刘易斯和马丁·福勒所发表的一篇博客中，总结了微服务架构设计的一些共同特点，这应该是一个对微服务比较全面的描述。有关这篇文章的详细内容可从下列链接中打开：
这篇文章中认为：“简而言之，微服务架构风格是将单个应用程序作为一组小型服务开发的方法，每个服务程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机器独立部署。这些服务可以用不同的编程语言编写，使用不同的数据存储技术，并尽量不用集中式方式进行管理。”
从这个描述中可以看出，微服务可以是一个小型的服务组件，它使用轻量的HTTP协议进行通信。微服务也可以是一个独立的应用程序，它可以具有独立的数据库、独立部署和独立运行。理想的想法是，微服务可以使用不同的语言来编写，并且完全独立自治。1.2 微服务的定义
从上面对微服务概念形成过程的介绍之中，我们已经对微服务有一个大概的了解，但要说明什么是微服务，很有可能一时也不能说得很清楚。这里，有一点容易混淆的就是微服务架构和微服务，这应该是两个不同的概念，而我们平时一说到微服务，可能已经包含了这两个概念，所以要把它们说清楚难免就会有一种很纠结的感觉。微服务架构是一种设计方法，而微服务应该是指使用这种设计方法而设计的一个应用。所以我们很有必要对微服务的概念做出一个比较明确的定义。
微服务架构是将复杂系统使用组件化的方式进行拆分，并使用轻量通信方式进行整合的一种设计方法。微服务就是通过这种架构设计方法拆分出来的一个独立的组件化小应用。
组件，通常是以代码库的形式，提供函数式调用；而微服务的组件，却以应用的方式，通过使用HTTP通信提供接口服务。
微服务架构定义的精髓，可以用一句话来描述，那就是“分而治之，合而用之”。将复杂系统进行拆分的方法，就是“分而治之”的方法。分而治之，可以让复杂的事情变得简单，这很符合我们平时处理问题的方法。使用轻量通信等方式进行整合的设计，就是“合而用之”的方法。合而用之，可以让微小的力量变得强大。硬件设计中多线程和多任务的技术，可以成倍地提高其并发能力和执行性能。如果软件设计还在使用单线程的方法，那是相当落后的。所以微服务设计中的整合，不但是多服务的整合，也是一种多实例、多副本的整合。通过这种整合，可以充分利用分布式环境的资源和低廉的机器组合成一个强大的服务系统。
微服务轻量级的HTTP通信，不同于传统的做法，使用事先设定的IP和端口进行访问，而是通过服务注册与发现的机制，使用服务的实例名称进行调用。在这个过程中，服务发现机制将协同路由代理服务和负载均衡器一起工作，当客户端使用服务实例名称发出请求时，将通过负载均衡器从服务注册列表中选择一个可用的服务实例，然后才通过实例注册的IP和端口路由到相关的服务中。所以提供API的微服务，可以发布在任意主机之中，并且可以随时更改主机和端口，也可以发布任意多个副本。
基于上面微服务的定义，我们可以总结出微服务架构设计的几个显著特点，具体如下。
1．小型化
微服务架构设计的突出之处就是进行服务组件化设计，组件化的结果最显著的特点就是应用程序变小了。使用组件化方式来构建的应用程序，每个组件将只负责完成一定范围的业务功能，更加专一地做好一件事情。因为小型化的特点，会让问题变得更加简单，也使开发变得更加容易。
2．自治化
使用去中心化的扁平化设计，将使每个服务都能够进行独立自治，这是对复杂功能的一种解耦设计。这种设计的特点也给每个微服务提供了更加自由的管理空间。
每个微服务都是一个独立的应用，独立使用数据库，独立部署，独立运行，这种独立性符合高内聚松耦合的设计原则。在微服务开发和维护中，每个微服务都是独立自治的，一个服务的更新和迭代将不存在对其他任何服务的依赖，同时也不会给其他服务造成影响，或者将这种影响减少到最小限度。
3．扁平化
独立自治的微服务，可以更加自由地发挥每一个服务的优势和长处。但是这种自由并不是指随意的混搭和组合，而是使用了扁平化的服务治理，让更多的微服务在发挥个性优势的同时，处在一种杂而不乱的有序可控的状态之中。虽然从整体上微服务已经没有集中管理的概念了，但是微服务在整体上能够发挥更佳的性能优势。
4．轻量级设计
微服务的组件化特点，也是一种轻量级设计方法的体现，这种轻量级的设计同样体现在微服务的通信设计之中。
微服务的通信设计通常用到两种方式，即使用API的同步通信和使用消息通道的异步通信，不管使用哪种通信方式，都没有像SOA的ESB（Enterprise Service Bus，企业服务总线）那样的重量级设计，而是分别使用简单的REST协议和轻量的消息总线来实现。
5．渐进式设计
一个产品从成型到成熟总是要经历一个过程，这个过程就是渐进式设计的特点。由于微服务小型而独立的特点，微服务设计可以使用业务驱动的方式进行，使用快速迭代进行不断地修正和调整，以使产品趋于成熟。1.3 微服务架构与整体式架构的区别
如果是一个小型项目，使用整体式架构来设计，其好处是明显的，因为它的设计、开发、测试和部署，都在一个项目上就可以完成。
如果一个业务复杂的大型项目，也使用整体式架构来设计，就将存在很多问题。可能刚开始的阶段，还感觉不到什么，但是随着时间的推移，加入的功能越来越多，一个项目就变成了一块巨大的石头，十分笨重。
面对一个如此巨大的项目，开发人员要弄清楚它的代码逻辑，必须要花费很多的时间。而针对某一项功能的更改，极有可能动一线而牵全身，这会让实施的人员变得很难应对。所以这种项目将会变得越来越难以维护，越来越不便更新。
整体式架构的稳定性也不能得到有效的保障，如果其中的一个模块出现问题，将会影响到整个系统的正常运行，甚至造成整个系统的崩溃。而要进行问题的跟踪，因为系统庞大，往往难上加难。
另外，一个巨大的应用项目，也不方便进行持续开发，它不能适应需求的变更，不能适应快速迭代的敏捷开发方法，所以这样的项目最终就变成了业务发展的绊脚石。
相比之下，大型项目使用微服务架构就具有明显的优势。
微服务架构设计，就是将复杂事情进行简单化处理的方法，它将一个复杂的系统，拆分成一些小型的应用来开发，起到了一种“大事化小，小事化无”的效果。因为简单，代码的逻辑会变得更加清晰，这无疑减轻了程序员繁重的劳动；因为简单，所以能够专注，能够将每一件事情做好，做到极致。
微服务中独立的小型应用，也非常适合使用敏捷开发方法，能够快速响应需求的变化，进行快速更新，快速迭代，甚至将一个应用推倒重来也是很容易做到的。
因为每个微服务都是独立自治的，一个服务的故障也不会影响到全局系统的正常运行，或者说可以将这种影响降到最低限度。况且，微服务架构的容错设计可以避免这种情况发生。
微服务架构高可用的特点是系统稳定性的最好保障，而且微服务能够支持高并发的调用，支持高流量的访问，能够持续保证平台规模化发展的要求，这是整体式架构所不能做到的。
如果我们使用一个六边形结构来表示整体式架构的话，将可以绘制出如图1-1所示的结构图。
这个六边形的核心是整体式架构的领域业务模型，它通过系统接口使用各种适配器，例如数据库适配器、文件适配器等，与外部管理系统进行连接。然后通过接口使用诸如Rest API适配器、Web UI适配器等对外部App和终端用户提供接口调用和Web访问等服务。
从图1-1中可以看出，整体式架构是一个大而全的系统。在微服务架构设计中，我们可以使用一个小六角形来表示每个微服务，它相当于将整体式架构进行拆分之后得到的结果，如图1-2所示。
小六角形的微服务同样使用接口，通过各种适配器来连接外部管理系统，而微服务之间也可以通过接口，使用Rest API适配器进行通信，而对于App和终端用户，将分别由不同的微服务提供相应的适配器及其服务。图1-1 整体式架构六边形结构图图1-2 微服务架构结构图
从上面这两种结构图形的比较中，可以非常明显地看出整体式架构与微服务架构的巨大区别。
有关这种图形结构的表示方式，参考了克里斯·理查德森在2015年5月发表的系列文章，对这些文章感兴趣的读者可以通过下列链接进行访问：1.4 微服务架构与SOA的比较
SOA（Service-Oriented Architecture，面向服务架构），是一种粗粒度、松耦合的面向服务架构设计方法。SOA可以看作B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。
SOA是一种企业级的架构设计方法，使用企业服务总线（ESB）的方式来构建一个更高效、更可靠、更具重用性的企业信息系统。相比于以往C/S和B/S等模式的设计，使用SOA架构的系统已经取得了很大的进步，系统可以更加从容地面对业务的急剧变化。所以SOA曾经风靡一时，例如Dubbo、Dubbox、Mule、WSO2、CXF等都是一些比较优秀的SOA开源工具。
微服务架构与SOA在表面看来还是有一点相似的，以至于早期有人会认为微服务是一个细粒度的SOA，其实它们的区别还是很大的。
微服务的轻量级设计与SOA重量级设计是这两种架构的最大区别。微服务的通信设计使用简单的HTTP协议，一般使用Restful实现。而SOA一般使用复杂的协议，如WebService或BPEL（Business Process Execution Language，业务流程执行语言）等，还需要使用服务描述性语言来定义标准接口。
微服务的自治性与SOA的集中式管理的区别：微服务架构使用去中心化的扁平化管理方式，每个服务都是一个独立的应用程序，独立管理，使用独立的数据库，独立部署和独立运行。SOA是一种整体式架构，使用集中式的管理方式和统一的数据中心。所以微服务的开发和部署更加灵活和快速，可以更快地响应需求的变化和业务的更新。
微服务架构与SOA的另一个区别是应用的规模不同，SOA是在企业计算领域中产生的一种架构设计方法，在应用规模上是一个有限的范围，而微服务架构是产生于互联网环境中的一种设计方法，它的设计更能适应无限广阔的环境，更能适应互联网高流量、高并发的规模扩张。
微服务架构的高可用设计、自由伸缩性、负载均衡、故障转移等特性是SOA设计不够重视的地方。微服务的高可用设计通过微服务治理，为每个微服务的管理和部署提供一个可以扩展的无限广阔的空间，它可以表现为一个三维结构，如图1-3所示。图1-3 微服务治理的三维结构
在这个三维结构中，如果我们用Y轴表示微服务应用，用X轴表示微服务应用部署的多个副本，那么用Z轴表示微服务治理，它将提供服务路由和负载均衡管理等功能，并且还可以提供分区管理的功能。1.5 为什么要使用微服务架构
从上面的比较可以看出，整体式架构已经不再适合于一个大型项目或者一个应用平台的开发，而SOA架构虽然曾经风靡一时，但是其重量级的设计也已经成为快速开发的障碍，所以这两种架构设计方法都将被微服务架构所取代。微服务架构轻量级的设计风格，不管从理论上还是从技术实现上，已经越来越多地得到更多人们的肯定和认可，大家对它的未来发展趋势都抱有一种乐观的态度。使用微服务的好处如下。
1．开发简单
微服务架构将复杂系统进行拆分之后，让每个微服务应用开发都变得非常简单，没有太多的累赘。对于每一个开发者来说，这无疑是一种解脱，因为再也不用进行繁重的劳动了，每天都在一种轻松愉快的氛围中工作，其效率将会成倍地提高。
2．快速响应需求变化
一般的需求变化都来自于局部功能的变更，这种变更将落实到每个微服务上，而每个微服务的功能相对来说都非常简单，更改起来非常容易，所以微服务非常适合敏捷开发方法，能快速响应业务需求的变化。
3．随时随地更新
一方面，一个微服务的部署和更新并不会影响到全局系统的正常运行；另一方面，使用多实例的部署方法，可以做到一个服务的重启和更新在不易被察觉的情况下进行。所以，每个微服务任何时候都可以进行更新部署。
4．系统更加稳定可靠
微服务运行在一个高可用的分布式环境之中，有配套的监控和调度管理机制，并且还可以提供自由伸缩的管理，充分保障了系统的稳定可靠性。
5．规模可持续扩展
每个互联网应用都具有巨大的市场潜力，一旦这种潜力被激发，就需要系统能支持大规模的高并发访问机制，使用微服务架构设计的系统，将能适应业务的快速增长，并可持续支持规模化的扩展。1.6 为实施微服务架构做好准备
相比于以往的设计方法，微服务是一个全新的设计观念，为了能够顺利地实施微服务架构设计，必须在前期做好充分的准备，在思想观念、团队管理和运维管理上进行相应的变革。1.6.1 思想观念的转变
开始进入微服务领域，必须从做项目的观念中转变到做产品的观念中来。如果是一个软件项目，在完成了业务需求的设计之后，最终交付使用，其项目开发的生命周期即宣告结束。而做产品就完全不一样，只要产品成型上线，产品有存在的价值，开发将永远没有终结，随着产品的更新换代，其中的应用程序和组件就要跟着不断地更新和迭代。
微服务架构中的渐进式设计的特点，就是一种做产品的观念的真实体现。一方面，一个产品的最初成型设计，由于种种原因并不可能把所有功能都考虑得很周到，这需要一定时间进行慢慢磨合；另一方面，市场总是在不断变化，所以产品的业务功能也应该随着时间的推移而发生一定的变化。
做产品的观念将贯穿于一个系统平台的整个生命周期之中，并随着平台的发展和演化，最终将产品打造成一个生态体系。1.6.2 团队管理方式的改变
传统的团队管理是按技术来进行分组的，在一个开发团队中，可能有UI设计组、前端开发组、后端开发组、测试组和运维组等的划分。
微服务架构的实施将按业务功能进行划分，所以对团队的管理最好应该以业务来进行分组，将产品设计、前端开发、后端开发、测试和运维等人员围绕业务功能分配在同一组中，这样不但可以增强团队的凝聚力量，而且也可避免将大量的时间浪费在不同组别的沟通和工作协调之上。
在实际的操作中，因为前端开发和运维管理的消耗并不是很大，所以这两部分的人员，可以进行机动调整，但这种调整最好也是在业务相近的领域中进行，并保持一定的连贯性，即原来由谁负责的工作，在更新和维护中还是由他来负责。
为了减少资源的浪费和增加每个人员的工作饱和度，一个业务小组往往并不只负责一个微服务，有可能会负责两三个微服务的开发，这主要看微服务划分的粗细粒度来定。1.6.3 自动化基础设施的建设
从整体式架构向微服务架构转变之后，项目会变得多起来，并且迭代的周期会越来越短，所以对测试和运维将在很大程度上提出更高的要求，并且其工作量也会比以前变得更多，所以单纯依靠人力来完成这两部分的工作是远远不够的，这就要求必须有自动化基础设施的支持，来完成自动集成、自动测试，以及持续交付、持续部署的工作。
一个原来可能几个项目就能支撑起来的应用平台，使用微服务架构进行拆分之后，可能会变成几十个项目，甚至上百个项目。所以如果还像原来那样分配测试和运维工作，将需要增加更多的人员配备。
在服务器资源的使用上，也相应地有所增加，但是因为每个微服务应用所占用的资源并不是很大，可以在原来的服务器中使用虚拟机技术来扩展服务器群组。对于微服务的部署，我们将主要使用Docker容器引擎来实施，这可以非常自由地将微服务分散部署在分布式环境之中。这样也就能更好、更有效地利用服务器的资源。1.7 为什么要使用Spring Cloud
微服务架构的实施和使用已经经历了一定的历程，在这一过程中，亚马逊、Netflix在使用微服务架构设计中成功的经验及其取得的成绩，是一个令人振奋的结果。特别是Netflix OSS开源组件的推出，更掀起了一番微服务的热潮。
Spring团队在Netflix OSS的基础上，推出了Spring Cloud微服务开发工具套件，极大地降低了微服务开发的门槛。使用Spring Cloud工具套件，可以让一个Java开发者，非常容易地开发微服务应用。
Spring Cloud专注于为典型用例和可扩展机制提供良好的开箱即用体验，涵盖了如下各个方面的功能。
·分布式/版本化配置。
·服务注册和发现。
·路由。
·服务之间调用。
·负载均衡。
·断路器。
·全局锁。
·主机选举和集群状态。
·分布式消息。
有了Spring Cloud，开发微服务应用就变得非常简单了。使用Spring Cloud，你可以在任何环境中进行开发和调试，包括自己的笔记本电脑、公司的局域网环境以及Cloud Foundry等托管平台。1.8 Spring Cloud组件介绍
1．Spring Cloud Config
配置管理工具包，可以将每个服务的配置放到远程服务器，实现集群化的集中管理，目前支持本地存储、Git以及Subversion等。
2．Spring Cloud Netflix
包含Netflix OSS的一些基础组件，如Eureka、Hystrix、Zuul、Archaius、Ribbon、Turbine等。
·Eureka是云端服务发现，用于云端服务注册与定位，以实现云端服务发现和故障转移等服务治理。
·Hystrix是一个集断路器、容错机制、降级机制等功能于一体的管理工具，通过这一工具可以实现对第三方库的延迟和故障转移提供全面监测和调控能力。
·Zuul是在云平台上提供动态路由、监控、安全等边缘服务的管理框架。Zuul相当于设备和微服务应用的Web网站后端所有请求的前门。
·Archaius是一个配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
·Ribbon提供云端负载均衡管理，有多种负载均衡策略可供选择，能自动配合服务发现和断路器使用。
·Turbine是聚合服务发送事件流数据的一个工具，使用可配置方式用来监控集群中服务的运行情况。
3．Spring Cloud Bus一个事件、消息总线，用于在集群中传播状态变化，可与Spring Cloud Config联合使用，实现动态配置管理。
4．Spring Cloud for CloudFoundry
通过配置协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
5．Spring Cloud CloudFoundry Service Broker
提供一个起点，为CloudFoundry建立托管服务代理。
6．Spring Cloud Cluster
提供Leadership选举，如Zookeeper、Redis、Hazelcast、Consul常见状态模式的抽象和实现。
7．Spring Cloud Consul
封装了Consul操作，Consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
8．Spring Cloud Security
基于Spring Security的安全工具包，可以为应用添加安全控制。
9．Spring Cloud Sleuth
日志收集工具包，封装了Dapper和log-based追踪，以及zipkin和HTrace操作，为微服务应用实现了一种分布式追踪解决方案。
10．Spring Cloud Data Flow
大数据操作工具，作为Spring XD的替代产品，它是一个混合计算模型，结合了流数据与批量数据的处理方式。
11．Spring Cloud Stream
数据流操作开发包，封装了与Redis、Rabbit、Kafka等发送和接收消息的方法。
12．Spring Cloud Stream App Starters
提供数据流基于Spring的与外部系统集成的方法。
13．Spring Cloud Task
提供云端计划任务管理与调度。
14．Spring Cloud Zookeeper
连接Zookeeper的工具包，用于使用Zookeeper方式的服务注册、发现与管理。
15．Spring Cloud Connectors
便于云端应用程序在各种PaaS平台连接到后端，如数据库和代理服务等。
16．Spring Cloud Starters
使用Spring Boot 方式的启动项目工具包，为Spring Cloud提供开箱即用的依赖管理。
17．Spring Cloud CLI
基于Spring Boot CLI，可以使用命令方式快速建立云应用。
18．Spring Cloud Contract
这是一个使用模拟测试的总体项目，其中包含帮助用户成功实施消费者驱动合同方法的解决方案。目前由Spring Cloud Contract Verifier项目组成。1.9 Spring Cloud的版本说明
截至本书定稿时，Spring Cloud及其组件版本对照如表1-1所示。表1-1 Spring Cloud及其组件版本对照表续表
其中，Spring Cloud的版本号为了与各个组件的版本号区分开来，使用了伦敦地铁站的名字来命名，并按字母顺序排列，截至目前，累计的版本有：Angel、Brixton、Camden、Dalston、Edeware、Finchley等，本书实例将使用上表中第三个发行版：Edgware.RELEASE，这是一个稳定版，对应的Spring Boot版本为1.5.9发行版。上表中的“M1”、“M2”等是指各个里程碑（Milestone）版本。
Spring Cloud的版本更新可留意其官方发布的信息：
打开上面链接，我们可以查看Edgware版本的POM（Project Object Model）配置，如图1-4所示。图1-4 Spring Cloud版本信息
当我们在一个工程中使用像图1-4一样的POM配置之后（如下所示），在工程中引用Spring Cloud的其他组件时就可以不用再指定版本号，它将根据表1-1的对应关系适配一个组件合适的版本。1.10 小结
本章介绍了微服务架构的基本概念及其特点，并且通过与整体式架构和SOA架构的比较，加深了对微服务的理解，同时也简要介绍了Spring Cloud工具套件中各个组件的功能，从中可以看出，使用微服务架构将使我们面对复杂系统时能够将工程设计变得更加简单，并且能够快速而从容地响应频繁的需求变更，而Spring Cloud配套和强大的功能，将使微服务的开发更加容易和高效。
下一章将介绍如何使用Spring Cloud工具来进行微服务架构设计，开始进行软件工程设计中的一种全新体验。2微服务架构最佳设计
从上章微服务架构的介绍中，我们知道，使用微服务架构有很多好处，并且在各个方面都有其独特的优势，但是，每一件事情都不是绝对的，使用微服务架构同时也充满着挑战。因此，我们必须在开始进行微服务架构设计时，进行全盘考虑，权衡利弊，才能做出合理的抉择，取得最佳的设计效果。
在微服务架构设计中，对复杂系统进行拆分之后，会不会产生一些新的问题呢？比如微服务之间的相互调用和通信会不会很复杂？由于每个微服务都有独立的数据库，那么分散的数据管理怎么保证数据的一致性？如果单个微服务的功能变更，会不会影响到多个微服务的正常运行？诚然，这些问题是确实存在的。在克里斯·理查德森所发表的有关微服务架构设计的博客文章中，在这方面也有详细的描述，总结起来包括如下几点：
·微服务的粗细粒度不好把握。
·分布式的微服务增加了服务之间相互调用及其通信的复杂性。
·分散的数据管理难以保证数据的一致性。
·由多个微服务组成的系统会增加集成测试的复杂性。
·单个服务的变更可能会影响到多个服务。
·部署的复杂性。
下面将说明如何通过合理的设计，不但可以解决上面提到的问题，并且能充分发挥微服务架构的优势，以达到一种扬长避短的目的。2.1 合理划分微服务
微服务架构设计的首要任务就是怎么合理地划分微服务，即怎么围绕业务功能来创建微服务。在进行微服务划分时，有关微服务粗细粒度的考虑，建议在平台创建的初始阶段，可以使用粗粒度的方法按业务功能进行划分。然后，随着业务的发展及其运营的情况，再依据发展规模考虑是否继续细分。下面将使用水平划分法和垂直划分法两种方法相结合的方式来创建微服务。
一方面，在水平方向上，按业务功能不同来划分微服务，并把这次划分所创建的微服务称为Rest API微服务。Rest API微服务负责业务功能的行为设计，主要完成数据管理方面的工作，并通过使用Rest协议对外提供接口服务。
另一方面，在垂直方向上，再以Rest API微服务为基础实现前后端分离设计，创建Web UI微服务。Web UI微服务不直接访问数据，而只专注于人机交互界面的设计，它的数据存取将通过调用Rest API微服务来完成。
这样，经过两次微服务划分，我们就可以创建出Rest API和Web UI两种类型的微服务，也就是说，我们只要使用两种类型的微服务，就可以构成一个复杂的业务系统。
使用Rest API和Web UI微服务，再结合高性能和高并发的设计，并通过微服务的多副本发布，就可以构成一个能适应任何规模访问的多维的稳定牢固的网格结构，并且这个网格结构还具有自由伸缩的特性，可以根据业务的发展规模进行缩编或者进行扩充，这样也就可以非常容易地搭建一个可持续扩展的系统平台。2.2 微服务治理
微服务架构的实施，将会产生出越来越多的微服务，而微服务的独立自治性及其设计的扁平化管理方法，都给每个微服务的开发、部署和更新提供了更大的灵活性，所以微服务的运行环境、服务间的相互调用将会变得越来越复杂。因此必须有一些组件和服务来对运行中的微服务进行有效治理，才能在一个庞大的分布式环境中保证每个微服务的运行和服务间的调用处在一种有序而不杂乱、稳定而高效的状态之中。
Spring Cloud工具套件使用了基于Netflix OSS的一些基础组件来实现微服务治理，这些组件主要包括：
·注册管理服务组件Eureka，提供服务注册和发现的功能。
·负载均衡服务组件Ribbon，提供负载均衡调度管理的功能。
·边缘代理服务组件Zuul，提供网关服务和动态路由的功能。
·断路器组件Hystrix，提供容错机制、服务降级、故障转移等功能。
·聚合服务事件流组件Turbine，可用来监控集群中服务的运行情况。
·日志收集组件Sleuth，可以通过日志收集提供对服务间调用进行跟踪管理的功能。
·配置管理服务组件Config，提供统一的配置管理服务功能。
这些组件是如何进行微服务治理的呢？如图2-1所示为一个微服务治理主要过程的序列图，可以用来简要说明微服务治理的工作原理。在这个序列图中，Eureka管理每个注册的微服务实例，并为其建立元数据列表，当一个服务消费者需要调用微服务时，Ribbon将依据微服务的实例列表实行负载均衡调度，这种调度默认使用了轮询算法，它将从实例列表中取出一个可用的实例，然后Zuul依据实例的元数据，对服务进行路由，在路由的过程中，Hystrix将检查这个微服务实例的断路器状态，如果断路器处于闭合状态，即提供正常的服务；当断路器打开时，说明服务已经出现故障，Hystrix将根据实例的配置情况实行故障转移、服务降级等使用机制。图2-1 Spring Cloud微服务治理序列图
另外，使用Turbine组件可以对运行中的微服务实现全面监控，使用Config可以构建一个在线更新的配置管理中心，使用Sleuth的日志收集功能，结合Zipkin的使用可以组建一个跟踪服务器。通过这些组件和服务的使用，将可进一步加强微服务治理的力度。
所以，通过Spring Cloud的工具组件进行微服务治理，微服务的运行就将处在一种有序可控的范围之中，微服务之间的相互调用和通信就会变得非常简单，并且快速而高效。2.3 Rest API微服务设计
通过围绕业务功能使用水平划分方法划分出来的Rest API微服务是一个独立的小应用，这种小应用具有独立的数据库，可以独立部署和独立运行。也就是说，每个Rest API微服务是完全独立自治的。
Rest API微服务需要实现两方面的功能：一方面，对内实现数据管理的功能；另一方面，对外提供API调用。
有关数据管理的功能，我们将使用Spring-Data-JPA来开发。JPA（Java Persistence API）使用存储库（Repositories）的方式来实现数据的持久化，可以简化很多开发工作。另外JPA面向对象的特点也适合使用领域驱动设计的方法进行建模，这些都符合微服务架构轻量级设计的特点。
接口的开发将根据Restful规范，使用如下所示的方法对外提供相应的数据服务：
·GET
·POST
·PUT
·DELETE
这些接口方法已经涵盖了数据的新增、查询、更新和删除等操作。
Rest API微服务的实现所体现出来的设计容易、开发简单、访问高效的特点，非常适合使用敏捷开发方法，也可以适应快速迭代和多副本发布的要求。
在我们的微服务架构设计中，Rest API微服务就相当于数据库调用的一个中间件，它的调用性能将对整个系统的性能起到决定性的作用。所以，高性能的Rest API微服务设计，就是微服务架构最佳设计中的一个重点所在。高性能的Rest API微服务设计，将主要通过下述一些方法来实现。2.3.1 使用数据库集群
在数据库集群设计上，我们将使用一种可扩展的分布式架构来实现，这种架构使用集群和分组设计，可以实现根据规模的发展情况提供可持续扩容的特性。
数据库的集群设计，主要通过主从同步的方式来扩展数据库的访问性能，通过建立多个只读的从机来缓解主机的读写压力。
集群的分组设计是分布式环境中一种高可用的设计，在一般情况下，可能只有一个分组提供正常的服务，其他分组只是充当冗余备份的角色，当提供正常服务的分组负载过高时，处于备份状态的分组才变成提供正常服务的角色。
这样，通过集群和分组相结合的方式，就可以充分提高数据库的访问性能。2.3.2 读写分离设计
使用数据库集群就可以进行读写分离设计。通过读写分离设计可以充分调用数据库集群和分组的资源。读写分离的设计将由数据库代理中间件来实现。数据库代理不但实现了读写分离的功能，也充当了集群分组负载均衡调度的角色。另外，数据库代理也为应用访问集群数据库，提供了一种完全透明的使用方法，即对于一个应用来说，它还是像以往使用单机数据库一样使用连接池，它并不清楚这种连接池里面还有一个巨大的集群体系。
另外，在读写分离设计中，还可以将数据存取进行分区设计，即使用分库分区表的方法，可以对单一表格的存储容量进行扩充，同时通过分区表设计，也能提高大容量数据的读取效率。2.3.3 使用缓存
使用数据缓存是一种提高数据的存取性能的方法，同理也是我们解决数据库主从设计中可能出现同步延迟的有效方法。
我们将使用Redis来实现缓存设计，Redis是一个高性能NoSQL数据库，并且具有非常高效的存取性能。Redis首先使用内存作为数据存取的缓冲区，同时也能将数据做持久化保存在磁盘中。
为了提高缓存的命中率，在缓存设计中必须遵循以下两点规定：
第一，不要在缓存中存取大容量的数据。
第二，合理设置每一个缓存数据的有效期，不将缓存数据做持久化保存。2.3.4 保证Rest API微服务的独立性
Rest API微服务是一个独立的应用，并且具有独立自治特性，但是如果在Rest API微服务之间进行互相调用，就将破坏这种独立性。所以，禁止在Rest API微服务之间进行互相调用，可以充分保证Rest API微服务的独立性，让Rest API微服务发挥最佳的性能效应。2.4 Web UI微服务设计
Web UI微服务是一个前端设计，它也可以使用Node.js、Angular.js或Vue.js等前端设计工具来进行开发。这里推荐使用Spring-Boot-Web来开发Web UI微服务，因为这样会更为简便和快速，并且与Spring Cloud工具也能够取得更多的默契和更多方面的搭配。
Web UI微服务的设计，包含了两个方面的功能：一方面实现对Rest API微服务的调用；另一方面是用户界面设计。Web UI微服务将面对最终用户，所以它必须能够适应规模化的访问。我们将通过下述一些方法来实现高并发的Web UI微服务的设计。2.4.1 使用FeignClient实现负载均衡调用
针对Rest API微服务对外提供的Restful的HTTP接口，我们将使用Spring Cloud工具套件中的FeignClient来进行访问，这个工具比起使用JS中的Ajax（Asynchronous Javascript And XML）或使用RestTemplate等工具都将更加高效和实用，而且使用更加简单。使用FeignClient通过声明式接口就可以实现HTTP调用，并且在调用的过程中，都将自动使用Zuul的动态路由和Ribbon的负载均衡服务。2.4.2 使用Hystrix实现容错设计
在分布式环境中，当一个服务超载甚至失效时，如果这时对其继续调用，因为得不到回应，就会进入不断的等待状态之中。如果这是一种连锁调用，甚至会引起系统的雪崩效应。所以必须有一种机制来处理这种情况，以起到防患于未然的作用，这种机制就是Hystrix组件的断路器功能，它的作用相当于电路设计中的保护开关，当服务不可用或超载时，断路器切断服务，提供降级使用机制，当服务恢复正常后，断路器将自动接通服务。
我们将在Web UI微服务设计中，使用Hystrix组件提供的功能来实现断路器的设计，提供对服务访问的容错设计和降级使用机制。2.4.3 使用非阻塞的异步编程技术实现高并发调用
Java开发语言从Java 8之后，提供了一种非阻塞的异步的多线程的回调处理方法，它封装在CompletableFuture类中，使用这种编程方法的强大功能，就可以实现Web UI微服务的高并发设计。2.4.4 使用分布式文件系统
在分布式系统中，最终用户使用的图片、视频等资源文件，必须使用一个独立的文件系统来管理。我们将使用轻量级的FastDFS来构建一个高可用的分布式文件系统，FastDFS是一个开源的分布式文件系统，它不但容易使用和维护，也方便进行扩容。
FastDFS由跟踪器（Tracker）和存储节点（Storage）两部分组成。
跟踪器管理所有的存储节点，并对存储节点的访问起到负载均衡调度的作用。通过配置多个跟踪器，可以构建一个高可用的文件系统。
存储节点用来存储文件，同时处理文件的存储、同步等管理工作。存储节点通常由多台服务器组成，每台服务器使用对等的设计，所以可以在任何时候进行增加或减少存储节点的数量。
为了支持大容量的文件存储，每个存储节点中使用了分组（或分卷）的设计，每个分组可以存储在不同的服务器上。
所以，使用FastDFS可为我们提供一个高可用和高性能的海量文件系统。2.5 微服务之间调用规则设计
为了保证各个微服务的独立性，并减少通信的复杂性，提高微服务之间的调用效率，我们对微服务之间的调用，做出了如下几种约定。
1．通过Web UI调用Rest API
服务之间的调用，主要是指Web UI微服务对Rest API微服务的调用。一个Web UI在一次调用之中，可以同时调用多个Rest API，并且这种调用将通过高并发设计来实现，即多个调用将会由不同的线程所执行，所以即使是多个调用，也不会影响程序的执行效率。
2．Rest API之间只能通过MQ进行互相通信
为了保证Rest API的高性能特性，同时避免因为一个Rest API的功能变更对其他Rest API的影响，所以禁止在Rest API之间进行相互调用。Rest API之间如果需要进行通信，可以使用异步消息来实现，即通过消息总线实现异步通信。
3．Web UI之间可使用与之对应的实例进行相互跳转
Web UI之间不进行相互调用，但可以进行相互跳转，这种跳转不是直接使用地址栏的链接来进行的，而是通过注册实例实现跳转，当一个注册实例有多个副本时，将可进行负载均衡管理。2.6 数据最终一致性设计
集中式的数据管理可以在一个事务中完成，所以能保证数据的高一致性。对于微服务的多服务架构，数据将由不同的微服务进行分散管理，所以要保证数据的一致性，必须有合理的设计。
假如我们有商品和订单两个微服务，那么在订单服务中生成订单时，将需要在商品服务中进行库存减少的操作，而在订单服务中进行订单查询时，将有可能需要在商品服务中查询订单相关的商品信息，这就涉及不同微服务中数据一致性的问题。
我们可以依据CAP原理的BASE理论来实现数据最终一致性设计。
CAP（Consistency，Availability，Partition tolerance）即一致性、可用性、分区容错性三者不可兼得。
BASE（Basically Available，Soft state，Eventually consistent）即基本可用、软状态、最终一致性。BASE是对CAP中一致性和可用性进行权衡的结果。
数据最终一致性设计具体的实现主要由两种类型的操作完成：一种是通过调用各个Rest API实现实时同步操作；另一种是使用消息通道以事件响应的方式进行异步处理。
比如在商品服务和订单服务的例子中，当用户下单时，即同时调用两个服务的Rest API，一方面，通过订单服务的Rest API生成订单，另一方面通过商品服务的Rest API更新库存数量。而当订单状态修改时，即由订单服务的Rest API发布一个异步消息，商品服务的Rest API通过订阅消息来执行相应的更新操作。2.7 分布式集群架构设计
通过微服务的治理环境，使用多副本发布的每个微服务，最终都将被自动纳入到微服务的负载均衡管理体系之中，这些微服务应用与我们搭建的数据库集群、分布式文件系统等集群一起构成一个分布式架构的集群体系，如图2-2所示。图2-2 微服务分布式集群体系结构
这个集群体系将由很多不同的服务器所组成，这些服务器既可以分布在同一个局域网之中，也可以进行跨区域、跨机房分布，组成一个庞大的分布式体系结构。总之，使用分布式集群架构设计，可以搭建一个稳定可靠并可持续扩展的系统平台。2.8 微服务运行环境安全设计
系统的安全设计包括防火墙设计、防攻击设计、访问控制设计、数据保密设计等各个方面的内容。而防火墙设计是系统安全的第一道屏障，我们将使用防火墙为微服务架构的服务器组建提供一个安全可靠的分布式环境，如图2-3所示。图2-3 微服务运行环境安全设计网络拓扑结构
使用防火墙，我们可以组建一个局域网环境，在这个局域网环境之中，各种服务器的组建将会更加容易，服务器的配置会更加简单，服务之间的通信也会更加方便和快速。
使用防火墙，我们还可以将不同区域、不同机房的服务器通过VPN连接起来，提供一种更加安全的访问方式。2.9 小结
本章介绍了怎么围绕业务功能来进行合理地划分微服务的方法，并在此基础上创建了两种类型的微服务，即专门用来存取数据的Rest API微服务和主要实现前端设计的Web UI微服务，使用这两种类型的微服务，通过微服务治理，并结合使用数据库集群设计、缓存设计、分布式文件系统设计、微服务的集群设计、安全的分布式环境设计等一系列分布式的架构设计，就可以构建成一个微服务架构的最佳设计，并在微服务架构本身所体现出来的优势和缺点之间进行权衡与调整，最终充分发挥微服务架构的绝对优势。
其中，有关微服务的集成测试和部署的复杂性问题，我们将在第三部分的运维篇中介绍使用自动化构建工具来解决。
下一章将使用这个最佳设计，通过一个电商平台实例来实现这种微服务架构设计。3电商平台微服务设计实例
上一章介绍了微服务架构的最佳设计方法，本章将使用这种方法通过一个电商平台实例来实现微服务架构设计。电商平台是一个大众化的应用平台，大家对它的功能都比较熟悉，我们将通过电商平台的微服务设计，体会微服务在实际生产中的具体使用方法。3.1 电商平台总体设计
电商平台是电子商务交易平台的简称，是指通过互联网为企业和个人提供网上交易的管理平台。电商平台可提供一个网上自由交易的场所，为普通用户（顾客）和虚拟商铺（商家）建立一种可信的买卖关系，通过互联网实现不受地域和时间等条件所限制的贸易行为。
我们将以一个通用的电商平台为例进行设计，但不做太多复杂的功能，也不关注太多的细节变化，我们只要求大体上能完成一个网上购物的流程，以此来体会微服务架构在实际应用中的使用方法。3.1.1 总体业务流程设计
如图3-1所示是电商平台的一个总体业务流程设计。图3-1 电商平台基本业务流程图
这个流程表示，顾客进行网上购物时将从浏览商品、挑选商品开始，然后经过结算、支付的过程，生成了一个交易的订单。商家通过后台的订单管理就可以确认顾客的交易行为，并联系物流公司进行发货处理。最后，顾客收到商品后即完成了一个正常的交易流程。顾客还可以对这次交易进行评价。
其中，在结算的过程中，如果顾客感到不满意，可以在一定的有效期内对生成的订单执行撤销交易的操作。
另外，如果顾客收到货物后对商品质量感到有问题，还可以申请售后服务或者直接提出退货，开启退货的申请流程。商家审核退货后，可以给顾客退回货款，从而结束一个交易。
要完成一个完整的交易过程，还将涉及其他业务流程的设计，这些流程包括如下几个方面的设计。
·顾客在购买商品之前，必须先进行平台用户的注册，然后执行个人基本资料的编辑，新增和维护收货地址等操作。平台顾客也可以注册为商家的会员，然后由商家提供会员级别的服务。
·商家将通过后台管理执行商品发布、订单管理、物流处理、退货审核、会员注册及其管理等基本操作流程。
·平台将对商家入驻有一个管理流程，包括商家的管理、商家注册与审核、商家权限管理等功能。3.1.2 总体业务功能设计
电商平台总体业务功能的设计包括如下几个方面。
·涉及商品展示方面的功能，将包括商品的类目配置及其管理、商品的库存、定价、商品信息编辑、商品上下架管理等内容。
·在进行交易操作方面，将包括顾客管理、会员管理、购物车管理、支付管理、订单管理、物流管理等方面的内容。
·在商家的管理方面，将包括商家的入驻与注册的审核、商家的操作权限配置、商家的账户管理、结账和对账等方面的内容。
上述这些功能，根据其面向的用户对象不同，可以将电商平台的总体业务功能分为：面向顾客的门户商城、面向商家的管理后台和面向平台运营方的管理后台三大部分，如图3-2所示。图3-2 电商平台总体业务功能结构图
其中，门户商城就相当于商家的店铺，是商家展示商品、顾客浏览商品并进行现场交易的地方。商家管理后台是商家进行商城事务日
试读结束[说明：试读内容隐藏了图片]