Spring Cloud初见（一）

首先声明，本文是大部分参考的《Spring Cloud微服务实战》一书，本人读书有记笔记的习惯，因此读此书时写成博客用于记录，此外大家查阅的过程中能有所收获也是我的荣幸，写的较差，大家海涵。如果作者对本博客有意见，请联系我，我会立即删除。

什么是微服务

    简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分为多个小型服务，这些小型服务都在各自独立运行，服务之间通过HTTP或是RESTful API进行通信协作，由于通信协议一致，所以这些微服务可以使用不同的变成语言。

与单系统的区别

    与传统的系统架构不同，我们将传统的业务分为三个主要部分：数据库，服务端处理，前端展现，在业务发展初期，这种架构易于，开发，测试，部署。但是随着业务的成长，系统渐渐变得臃肿，单体项目被划分为不同个模块；同时随着移动端设备的进步，前端模块已经不仅仅局限于Web的形式，这对于系统向前端的支持西药更多的接口模块。单体应用由于面对的业务需求更为宽泛，不断扩大的需求会将单体应用变得越来越臃肿，单系统的问题就会越来越凸现出来。

    所以为了解决单系统适应业务规模增加的问题。微服务架构诞生了，我们将系统中的不同功能，模块拆分成多个不同的服务，这些服务都能够独立的部署和扩展。由于每个服务都运行在自己的进程内，在部署上有更加稳固的边界，我们可以更准确的为每个服务评估性能容量，通过配个服务间的协作流程也可以更容易的发现系统的瓶颈...当然这些都是微服务的优势了。

如何实施微服务

    在实施微服务前，我们必须要知道引入微服务会引发原本在单应用中没有的问题。

• 运维的新挑战：在微服务架构中，运维人员需要维护的进程大大增加，要知道，有条不紊的将这些进程编排和组织起来不是一件容易的事，所以我们需要运维人员具备一定的开发能力，来编排运维过程并让他们自动化运行。
• 接口的一致性：虽然我们拆分了服务，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为了服务间的通信依赖。所以我们需要更完善的接口和版本管理。或是严格的遵循开闭原则。
• 分布式的复杂性：由于缠粉后的哥哥微服务都是独立部署并运行在各自的进程内，他们只能通过通信来进行协作，所以分布式环境的问题都将是微服务架构系统设计是需要考虑的重要因素，比如网络延迟，分布式事务，异步消息等。

    在架构师对于一个大型系统架构的设计与实施的过程中，面对环境，资源，团队等各种因素的影响，几乎不会出现完全相同的架构设计。对于微服务架构而言更是如此，因此并没有一个标准或是正式的定义，Martin Fowler在Microservices一文中，提炼出了为服务架构的九大特性，用于指导大家设计架构。

    服务组件化

    组件，是一个可以独立更换和升级的单元，像一台PC的硬盘，内存一样，独立且可以更换升级而不影响其他单元。在微服务架构中，需要我们对服务进行组件化分解。服务是一种进程外的组件，它通过HTTP等通信协议进行协作，而不像传统组件那样以嵌入的方式协同工作。每一个服务都独立开发，部署，可以有效避免一个服务的修改引起真个系统的重新部署。

    按业务组织团队

    当决定如何划分微服务时，通常也意味着我们要开始对团队进行重新规划与组织。按以往的方式，我们往往会从技术的层面将团队划分为多个，比如DBA团队，运维团队，后端团队，前端团队。而在微服务架构中，当有一个服务出现问题需要更改的时候，比如需要对某个表增加一个字段，这需要从数据存储开市考虑一直到设计和前端，虽然大家的改动都很小，但是这会引起跨团队的时间耗费和预算审批。

    在实施微服务架构时，需要采用不同的团队分割方法，由于每一个微服务都是针对特定业务的宽栈或是全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的职能。因此，面对大型项目的时候，对于微服务团队的拆分更加建议按业务线的方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队边界可以变得更为清晰。

    做“产品”态度

    在实施微服务架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的模式，以完成开发与交付并将结果交给维护者为最终目标。开发团队通过了解服务在具体生产环境中的情况，可以增加他们对具体业务的理解。所以我们需要用做“产品”的态度来对待每一个微服务，持续关注服务的运作情况，并不断分析以帮助用户来改善业务功能。

    智能端点与哑管道

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

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

    去中心化治理

    当我们采用集中化的架构治理方案时，同化成那个在技术平台上会制定一个统一的标准，但是每一种技术平台都有其短板，因此在实施为服务架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样真个微服务架构系统中的各个组件就能针对其不同的业务特点选择不同的技术平台。

    去中心化管理数据

    我们在实施微服务架构时，都希望让每一个服务来管理其自有的数据库，这就是数据管理的去中心化思想。在去中心化过程中，我们除了将原数据库中存储内容拆分到新的同平台的其他数据库实例之外（如把原本存储在MySQL中的表拆分后，存储到多个不同的MySQL实例中），也可以将一些具有特殊结构或业务特性的数据存储到一些其他技术的数据库实例中（如把日志信息存储到MongoDB中或把用户登录信息存储到Redis中）。

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

    基础设施自动化

    当我们实施微服务架构时，数据库，应用程序的个头都变小了，但是因为拆分的原因，数量成倍增加。所以运维人员需要关注的内容页成倍增加，并且操作性任务也会成倍增长。在微服务架构中，务必从一开始就构建“持续交付”平台来支撑整个实施过程，该平台需要两大内容，缺一不可。

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

    容错设计

    在单体应用中，一般不存在单个组件故障而其他部件还在运行的情况，通常都是“唇亡齿寒”要挂全挂。而在为服务架构中，由于服务独立运行，所以出现部分服务故障，其他服务正常运行，或是集群中的部分服务挂了，整体还是可用的，体现出来就是，这个服务有点卡。而之后产生的连锁反应：比如，当正常运行的服务B调用故障服务A时，因故障服务A没有返回，线程挂起时开始等待，知道超时才释放，此时若触发服务B调用服务A的请求来自服务C，而服务C频繁调用服务B时，由于其依赖服务A，大量线程被挂起等待，最后导致服务C也不能正常服务，这时就会出现故障的蔓延。

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

    演进式设计

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

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

Spring Cloud简介

    至于为什么选择Spring Cloud？我们可以看到在服务端领域，有太多的架构师和开发者在实际项目中针对不同的应用场景提供的各种解决方案和开源框架，其中不乏国内的互联网企业。

• 服务治理：阿里巴巴开源的Dubbo和当当网在其基础上扩展的DubboX，Netflix的Eureka，Apache的Consul等。
• 分布式配置管理：百度的Disconf，Netflix的Archaius，360的QConf，Spring Cloud的Config，淘宝的Diamond等
• 批量任务：当当网的Elastic-Job，LinkedIn的Azkaban，Spring Cloud的Task等
• 服务跟踪：京东的Hydra，Spring Cloud的Sleuth，Twitter的Zipkin等

    ......

    以上列举了一些在实施微服务架构时期，需要被我们考虑的问题，以及针对这些问题的解决方案。而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.Zuul：网关组件，提供智能路由，访问过滤等功能

            6.Archaius：外部化配置组件。

• Spring Cloud Bus：事件，消息总线，用于传播急群众的状态变化或事件，以触发后续的处理，比如用来动态刷新配置等
• Spring CLoud Cluster：针对ZooKeeper，Redis，Hazelcast，Consul的选举算法和通用状态模式的实现。
• Spring Cloud CloudFoundry：与Pivotal Coudfoundry的整合支持。
• 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 Starter：Spring Cloud的基础组件，它是基于Spring Boot风格项目的基础依赖模块
• Spring Cloud CLI：用于在Groovy中快速创建Spring Cloud应用的Spring Boot CLI插件