什么是微服务架构

           简单地说， 微服务是系统架构上的 一 种设计风格， 它的主旨是将 一 个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RE STful API进行通信协作。 被拆分成的每 一 个小型服务都围绕着系统中的某 一 项或 一些耦合度较高的业务功能进行构建， 并且每个服务都维护着自身的数据存储、 业务开发、自动化测试案例以及独立部署机制。 由千有了轻量级的通信协作基础， 所以这些微服务可以使用不同的语言来编写。

与单体系统的区别

         在项目中我们通常将需求分为三个主要部分： 数据库、 服务端处理、 前端展现。 单体系统在初期虽然可以非常方便地进行开发和使用， 但是随着系统的发展， 维护成本会变得越来越大， 且难以控制。 单体系统在初期虽然可以非常方便地进行开发和使用， 但是随着系统的发展， 维护成本会变得越来越大， 且难以控制。

如何实施微服务

        Martin Fowler 在 Microservices 一 文中，提炼出了微服务架构的九大特性， 用于指导大家设计架构。

        1、服务组件化

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

       2、按业务组织团队

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

      3、做 “ 产品 ” 的态度

      在实施微服务架构的团队中， 每个小团队都应该以做产品的方式， 对其产品的整个生命周期负责。 而不是以项目的模式，以完成开发与交付并将成果交接给维护者为最终目标。
      开发团队通过了解服务在具体生产环境中的情况， 可以增加他们对具体业务的理解，比如， 很多时候， 一 些业务中发生的特殊或异常情况， 很可能产品经理都并不知晓， 但细心的开发者很容易通过生产环境发现这些特殊的潜在问题或需求。所以， 我们需要用做 “ 产品”的态度来对待每 一 个微服务， 持续关注服务的运作情况，并不断分析以帮助用户来改善业务功能。

     4、智能端点与哑管道

     在微服务架构中， 通常会使用以下两种服务调用方式：
            • 第 一 种， 使用 HTTP 的 RESTful API 或轻量级的消息发送协议， 实现信息传递与服务调用的触发。
            • 第二种， 通过在轻量级消息总线上传递消息， 类似 RabbitMQ 等 一 些提供可靠异步交换的中间件。

     5、去中心化治理

     当我们采用集中化的架构治理方案时， 通常在技术平台上都会制定统 一 的标准， 但是每 一 种技术平台都有其短板， 这会导致在碰到短板时， 不得不花费大力气去解决， 并且可能因为其底层原因解决得不是很好， 最终成为系统的瓶颈。
     在实施微服务架构时， 通过采用轻量级的契约定义接口， 使得我们对于服务本身的具体技术平台不再那么敏感， 这样整个微服务架构系统中的各个组件就能针对其不同的业务特点选择不同的技术平台， 终千不会出现杀鸡用牛刀或是杀牛用指甲钳的尴尬处境了。

    6、去中心化管理数据

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

    7、基础设施自动化

     在微服务架构中， 务必从 一 开始就构建起 “ 待续交付 ” 平台来支撑整个实施过程， 该平台需要两大内容， 缺 一 不可。
           • 自动化测试：每次部署前的强心剂， 尽可能地获得对正在运行的软件的信心。
           • 自动化部署：解放烦琐枯燥的重复操作以及对多环境的配置管理。

    8、容错设计

     在单体应用中， 一 般不存在单个组件故障而其他部件还在运行的情况， 通常是 一 挂全挂。 而在微服务架构中， 由于服务都运行在独立的进程中， 所以存在部分服务出现故障，而其他服务正常运行的情况。 比如， 当正常运作的服务B调用到故障服务A时， 因故障服务 A 没有返回， 线程挂起开始等待， 直到超时才能释放， 而此时若触发服务 B 调用服务 A的请求来自服务 C, 而服务 C 频繁调用服务 B 时， 由千其依赖服务 A, 大量线程被挂起等待， 最后导致服务A也不能正常服务， 这时就会出现故障的荽延。
    所以， 在微服务架构中， 快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的。 通常， 我们都希望在每个服务中实现监控和日志记录的组件， 比如服务状态、 断路器状态、 吞吐量 、 网络延迟等关键数据的仪表盘等。

   9、演进式设计

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

为什么选择Spring Cloud

     目前分布式应用的一些开源框架：
     • 服务治理：阿里巴巴开源的Dubbo和当当网在其基础上扩展的DubboX、 Netflix的Eureka、Apache的Consul等。
     • 分布式配置管理：百度的Disconf、 Netflix的Archaius、360的QConf、SpringCloud的Config、 淘宝的Diamond等。
     • 批量任务：当当网的Elastic-Job、 Linkedln的Azkaban、 SpringCloud的Task等。
     • 服务跟踪：京东的Hydra、SpringCloud的Sleuth、Twitter的Zipkin等。 ． ．．．．．． 

     Spring Cloud的出现，可以说是对微服务架构的巨大 支持和强有力的技术后盾。它不像我们之前所列举的框架那样， 只是解决微服务中的某 一 个问题， 而是 一 个解决微服务架构实施的综合性解决框架， 它整合了诸多被广泛实践和证明过的框架作为实施的基础部件，又在该体系基础上创建了 一 些 非常优秀的边缘组件。

Spring Cloud简介

       Spring Cloud是 一 个基千Spring Boot实现的微服务架构开发 工具。 它为微服务架构中涉及的 配置管理、 服务治理、 断路器、 智能路由、微代理、 控制总线、 全局锁、 决策竞选、分布式会话和集群状态管理等操作提供了 一 种简单的开发方式。
       Spring Cloud包含了多个子项目（针对分布式系统中涉及的多个不同开源产品，还可能会新增）， 如下所述。
       • Spring Cloud Confi g:  配置管理工具， 支持使用Git存储 配置内容， 可以使用它实现应用配置的外部化存储， 并支持客户端配置信息刷新、 加密／解密配置内容 等。
       • Spring Cloud Netflix:  核心 组件， 对多个Netflix OSS开源套件进行整合。
              • Eureka:  服务治理组件， 包含服务注册中心、 服务注册与发现机制的实现。
              • Hystrix: 容错管理组件，实现断路器模式， 帮助服务依赖中出现的延迟和为故障提供强大的容错能力。
              • Ribbon: 客户端负载均衡的服务调用组件。
              • Feign:  基于伈bbon 和 Hystrix 的声明式服务调用组件。
              • Zuul:  网关组件， 提供智能路由、 访问过滤等功能。
              • Archaius:  外部化配置组件。
       • Spring Cloud Bus:  事件、 消息总线， 用于传播集群中的状态变化或事件， 以触发后续的处理， 比如用来动态刷新配置等。
       • Spring Cloud Cluster:  针对 ZooKeeper、 Redis、 Hazelcast、 Consul 的选举算法和通用状态模式的实现。
       • Spring Cloud Cloudfoundry:  与 Pivotal Cloudfo undry 的整合支持。
       • Spring Cloud Consul:  服务发现与配置管理工具。
       • Spring  Cloud Stream:  通过 Redis、 Rabbit 或者 Kafka 实现的消费微服务， 可以通过简单的声明式模型来发送和接收消息。
       • Spring Cloud A WS:  用千简化整合 Amazon Web Service 的组件。
       • Spring Cloud Security:  安全工具包， 提供在 Zuul 代理中对 0Auth2 客户端请求的中继器。
       • Spring Cloud Sleuth:  Spring Cloud 应用的分布式跟踪实现， 可以完美整合 Zip虹n。
       • Spring Cloud ZooKeeper:  基于 ZooKeeper 的服务发现与配置管理组件。
       • Spring Cloud Starters:  Spring Cloud 的基础组件， 它是基于 Spring Boot 风格项目的基础依赖模块。
       • Spring Cloud CLI:  用于在 Groovy 中快速创建 Spring Cloud 应用的 Spring Boot CLI插件。
       ． ．．．．．． 
       本书将对其中 一 些较为常用的组件进行介绍、 分析， 并演示其使用方法。

版本说明

版本名与版本号

       这些版本的名字采用了伦敦地铁站的名字， 根据字母表的顺序来对应版本时间顺序，比如最早的Release版本为Angel, 第二个Release版本为Brixton ……
       经过上面的解释， 不难猜出， 之前所提到的 Angel.SR6、Brixton.SRS中的 SR6、SRS就是版本号了。
       当 一 个版本的Spring Cloud项目的发布内容积累到临界点或者 一 个严重bug解决可用后， 就会发布 一 个"service releases"版本， 简称SRX版本， 其中 X是 一 个递增的数字，所以Brixton.SRS就是Brixton的第5个Release版本。
       Brixton的发布子项目更为稳定， Camden则更为前瞻。

         由于Brixton版本包含了大部分的Spring Cloud 子项目， 并且均为Release版本， 所以本文所有示例以及讲解内容的编写均采用 Brixton.SR5版本， 基千Spring Boot 1.3.7版本。
         注意：在本书完成时， Brixton版本已经升级到SR7, 本书中的示例均可直接使用Brixton.SR7来完成，但是在使用Brixton版本的时候需要注意Spring Boot的版本，必须使用1.3.x版本， 而不能使用1.4.x版本， 否则会出现各种问题。若 — 定要使用Spring 1.4.x版本的话， 必须将Spring Cloud版本升级到Camden版本， 目前Camden已经发布Release版本， 所以可以放心使用， 最新版本为 Camden.SR3。
        另外， Camden版本虽然可以兼容 Brixton版本中的 各种实现方法， 但是在升级后读者会发现有一些方法已经被标注为过期， 对于这些过期的使用方法， 笔者后续会在博客中逐个编写博文来说明这些更新内容。 所以， 有兴趣的读者可以关注我的博客(http://blog.d心space.com),  来持续获取Spring Cloud的 — 些最新动态。