第一章 基础知识

什么是微服务架构？

　　微服务架构实际上是一种设计风格，它的核心主旨是将一个独立的系统拆分为一个个的小型服务，每个小服务在各自的进程中运行，服务之间通过基于HTTP协议的restful API进行通信合作。各个小服务都围绕系统中的某一个或某一项耦合度较高的业务功能进行部署，每个小服务都维护自身的开发和部署机制。

 

与单体系统的区别

　　在传统的企业中，针对一些复杂的业务功能通常使用对象或业务类来构建一个单体项目。在项目中，通常将业务需求分为：数据库、服务端处理、前端展现。在发展初期，所有的业务功能在一个项目中，部署发布都还比较简单。随着企业的发展，业务需求不断的扩张，不断的为该项目增加业务模块；同时随着移动端的发展，后端的接口需要提供更多的接口来满足不同的展现形式。此时，单体项目变得越来越臃肿，越来越不好维护，往往修改了一个很小的功能就会影响其他的业务功能运行。随着这些问题的出现，微服务架构的作用逐渐凸显出来，将不同的业务功能模块拆分为不同的服务，每个服务之间独立运行，一个业务功能的修改不会影响其他服务的运行，而且还能更为准确的定位为题，为每个服务评估性能容量等。

 

如何实施微服务

　　经过多年的发展，Martion Fowler在Microservices一文中，提炼出了微服务的九大特性，用于指导大家设计架构。

 

服务组件化

　　组件是一个可以独立更换和升级的单元。在微架构中，需要对服务进行组件化的分解。服务，是一种进程外的组件，它通过HTTP协议等进行协作，而不像传统组件一样以嵌入的方式进行协作。每个服务都是独立运行和部署，有效的避免了因一个服务的修改导致整个项目重新部署的局面。

 

按业务组织团队

　　当决定要划分微服务时，往往还需要对业务团队进行重新规划和组织。按照以往的方式，我们会将业务团队分为DBA、运维、后端、前端等，如果我们继续按照这种方式，那么一个小小的改动可能会让整个团队都参与进来，增加了时间消耗和预算。比如：需要在数据库增加一个字段，需要从数据库到前端全面的修改。

　　所以，在进行微架构时，需要按照不同的方式划分。由于每个微服务都是针对特定的业务进行全栈操作。因此建议对微服务的团队也按照业务线进行划分。

 

做“产品”的态度

　　在实施微服务的每个小团队中，都要以做产品的方式，对其产品的整个生命周期负责，而不是像做项目一样，以开发和交付成果为最终目的。

 

智能端点与哑管道

　　在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在“微服务”架构中，服务由于不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改成RPC方式的调用，会导致微服务之间产生繁琐的通信，使得系统表现更为糟糕，所以，我们需要更粗粒度的通信协议。

　　在“微服务”架构中，通常会使用这两个服务调用方式：

• 第一种，使用HTTP协议的RESTful API或轻量级的消息发送协议，来实现信息传递与服务调用的触发。
• 第二种，通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的结构。

 

去中心化治理

　　在采用集中化的结构去治理方案时，通常会在平台上指定统一的标准以满足不同的平台，但不同平台都有其短板，当聚集在一起时有可能会造成一些瓶颈问题，采用微架构处理时就不必担心这些问题，每个服务都是轻量级的，可以根据不同的服务采用不同的技术平台，不会造成滥用的情况。

 

去中心化管理数据

　　在微架构中，每个服务都独自管理其自有的数据库，这就是数据管理的去中心化。

　　在去中心化的过程中，我们除了将原数据库中的存储内容拆分到新的平台的其他数据库中（如将原本存储在MySQL中的表拆分后，存储到多个不同的MySQL实例中），也可以将一些具有特殊结构或业务特性的数据存储到一些其他技术的数据库中（如：把日志信息存储到MongoDB中、把用户登录信息存储到Redis中）。

　　虽然，数据管理的去中心化可以让数据管理更加细致化，通过采用更合适的技术来让数据存储和性能达到最优。但是，由于数据存储于不同的数据库实例中后，数据一致性也成为“微服务”架构中急需解决的问题之一。分布式事务的实现，本身难度就非常大，所以在“微服务”架构中，我们更强调在各服务之间进行“无事务”的调用，而对于数据一致性，只要求数据在最后的处理状态是一致的效果；若在过程中发现错误，通过补偿机制来进行处理，使得错误数据能够达到最终的一致性。

 

基础设施自动化

　　近年来云计算服务与容器化技术的不断成熟，运维基础设施的工作变得越来越不那么难了。但是，当我们实施“微服务”架构时，数据库、应用程序的个头虽然都变小了，但是因为拆分的原因，数量成倍的增长。这使得运维人员需要关注的内容也成倍的增长，并且操作性任务也会成倍的增长，这些问题若没有得到妥善的解决，必将成为运维人员的噩梦。

所以，在“微服务”架构中，请务必从一开始就构建起“持续交付”平台来支撑整个实施过程，该平台需要两大内容，不可或缺：

• 自动化测试：每次部署前的强心剂，尽可能的获得对正在运行软件的信心。
• 自动化部署：解放繁琐枯燥的重复操作以及对多环境的配置管理。

 

容错设计

　　在单体应用中，一般不存在单个组件故障而其他还在运行的情况，通常是一挂全挂。而在“微服务”架构中，由于服务都运行在独立的进程中，所以是存在部分服务出现故障，而其他服务都正常运行的情况，比如：当正常运作的服务B调用到故障服务A时，因故障服务A没有返回，线程挂起开始等待，直到超时才能释放，而此时若触发服务B调用服务A的请求来自服务C，而服务C频繁调用服务B时，由于其依赖服务A，大量线程被挂起等待，最后导致服务A也不能正常服务，这时就会出现故障的蔓延。

所以，在“微服务”架构中，快速的检测出故障源并尽可能的自动恢复服务是必须要被设计和考虑的。通常，我们都希望在每个服务中实现监控和日志记录的组件，比如：服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。

 

演进式设计

　　通过上面的几点特征，我们已经能够体会到，要实施一个完美的“微服务”架构，需要考虑的设计与成本并不小，对于没有足够经验的团队来说，甚至要比单体应用发付出更多的代价。

所以，很多情况下，架构师们都会以演进的方式进行系统的构建，在初期系统以单体系统的方式来设计和实施，一方面系统体量初期并不会很大，构建和维护成本都不高。另一方面，初期的核心业务在后期通常也不会发生巨大的改变。随着系统的发展或者业务的需要，架构师们会将一些经常变动或是有一定时间效应的内容进行“微服务”处理，并逐渐地将原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的就形成了一个核心“微服务”存在于整个架构之中。

 

为什么选择Spring Cloud

 

　　近几年很多人对微架构的热情非常高，但是回头看微架构被提及也有很多年了。无数的架构师和开发者在实际项目中实践该设计理念并付出了诸多的努力。同时也分享了在微架构服务中针对不同场景出现的各种问题的各种解决方案和开源框架。如：

服务治理：阿里巴巴开源的Dubbo和当当网在其基础上扩展的DubboX、Netflix的Eureka、Apache的Consul等。

分布式配置管理：百度的Disconf、Netflix的Archaius、360的Qconf、Spring Cloud的Config、淘宝的Diamond等。

…………

　　Spring Cloud不像上述框架一些只解决服务中的某一个问题，而是一个解决微服务架构实施的综合性框架。

 

Spring Cloud简介

 

　　spring cloud是一个基于spring boot实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式回话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud包含了多个子项目，如下所述：

• Spring Cloud Config：配置管理工具，支持使用Git存储配置内容，可以使用它实现应用配置的外部化存储，并支持客户端配置信息刷新、加密/解密配置内容等。
• Spring Cloud Netflix：核心组件，对多个Netflix OSS开源套件进行整合。

1. Eureka：服务治理组件，包含服务注册中心、服务注册与发现机制的实现。
2. Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。
3. Ribbon：客户端负载均衡的服务调用组件。
4. Feign：基于Ribbon和Hystrix的声明式调用组件。
5. Zull：网关组件，提供智能路由、访问过滤等功能。
6. Archaius：外部化配置组件。

• Spring Cloud Bus：事件、消息总线，用于传播集群中的状态变化或事件，以触发后续的处理，比如用来动态刷新配置等。
• Spring Cloud Cluster：针对Zookeeper、Redis、Hazelcast、Consul的选举算法和通用状态模式的实现。
• Spring Cloud Cloudfoundry：与Pivotal Cloudfoundry的整合支持。
• Spring Cloud Consul：服务发现与配置管理工具。
• Spring CLoud Stream：通过Redis、Rabbit或者Kafka实现的消费微服务，可以通过简单的声明式模型来发送和接收消息。
• Spring Cloud AWS：用于简化整合Amazon Web Service的组件。
• Spring Cloud Security：安全工具包，提供在Zuul代理中对OAuth2客户端请求的中断器。
• Spring Cloud Sleuth：Spring Cloud应用的分布式跟踪实现，可以完美整合Zipkin。
• Spring Cloud Zookeeper：基于Zookeeper的服务发现与配置管理组件。
• Spring Cloud Starters：Spring Cloud的基础组件，它是基于Spring Boot风格项目的基础依赖模块。
• Spring Cloud CLI：用于在Groovy中快速创建Spring Cloud应用的Spring Boot CLI插件
• …………

 

版本说明

版本名与版本号

　　由于Spring Cloud不像Spring社区其他一些项目那样相对独立，它是一个拥有诸多子项目的大型综合项目，其包含的各个子项目也都独立进行内容更新和迭代，各自都维护着自己的发布版本号。因此每一个Spring Cloud的版本都包含多个不同版本的子项目，为了管理每个版本的子项目清单，避免Spring Cloud的版本号与其子项目的版本号相混淆，没有采用版本号的方式，而是通过命名的方式。

　　这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，比如最早的Release版本为Angel，第二个Release版本为Brixton……

　　当一个版本的Spring Cloud项目的发布内容积累到临界点或者一个严重bug解决可用后，就会发布一个“service release”版本，简称SRX版本，其中X是一个递增的数字，所以Brixton.SR5就是Rrixton的第5个Release版本。

 

版本区别

 

　　从上图可知，Angel拥有的子项目较少，Brixton、Camden拥有更全的子项目，而Brixton的发布子项目更为稳定且包含了大部分的Spring Cloud子项目，所以后续的示例以及讲解内容都采用Brixton.SR5版本，基于Spring boot 1.3.7以上版本。