第一章 基础知识

什么是微服务架构？

　　微服务架构其实是一种设计风格，它的核心主旨是将一个独立的系统拆分为一个个的小型服务，每一个小服务在各自的进程中运行，服务之间经过基于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以上版本。