什么是微服务架构？微服务架构有什么特性？为什么选择Spring Cloud？

1.学习目标

​ 无论是初学者还是有很久工作经验的工作者，希望大家能明白以下几个问题：什么是微服务架构？微服务架构有什么特性呢？为什么要用SpringCloud?自己根据自己之前的理解，尝试回答下这几个问题，看看自己的答案和下面的有什么不同，这样可以让我们记忆更加深刻。

2.什么是微服务架构？

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

​ 理解：微服务实际就是一种系统架构的设计方式，它是将系统按功能模块拆分多个服务。但是在真实使用中切忌为了技术而去使用技术（当手里有把锤子，看啥都像颗钉子），要根据业务模块的更新速度，并发量，以及模块功能的大小（如果一个模块10几个接口，独立出去既浪费了数据库连接数，还让运维复杂度增加，这仅代表个人理解）。

3.微服务架构有什么特性？

服务 组件化

​ 什么是组件？组件是一个可以单独更换和升级的单元。像PC的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。

​ 在微服务架构中，需要我们对微服务进行组件化分解。服务，是一种进程为的组件，他通过HTTP等通信协议进行协作，而不是像传统的组件那样以嵌入的方式协同工作。每一个服务都独立开发、部署，可以有效避免一个服务的更新引起整个系统的重新部署。

​ 理解：不仅仅服务需要组件化，在编写服务的时候也需要有组件化的思维，将一个业务拆分成多个方法，每个都可以独立业务而去使用，让方法独立与特定特务，成为一个标准的功能的方法。

按业务 组织团队

​ 之前的团队是按技术栈划分，例如DBA团队、运维团队、后端团队，前端团队，设计团队，需求团队等。
微服架构中，需要按照功能模块来划分团队。由于每一个微服务都针对特定业务的宽栈或全栈实现，既要负责数据的持久化存储，又要负责用户和接口定义等各种跨专业领域的职能。因为面对大项目的时候，对于微服务团队的拆分建议按业务条线方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队的边界可以变得更加清晰。

​ 理解：实际就是对开发的要求提高了，随着近些年的敏捷管理，要求开发是全栈的，这样可以节省前后端开发的沟通时间，并且也可以让开发的职责更加清晰（开发是提速了，但是业务可能从之前的多个开发知道，变成一个开发知道，需要解决业务壁垒）。

做“产品”的态度

​ 在微服务架构的团队中，每个小团队都应以做产品的方式，对其产品的整个生命周期负责。而不是以项目模式，已完成开发与交付并将成果交给维护者为最终目标。

​ 开发团队通过了解服务在具体生产环境中的情况，可以增加对具体业务的理解（产品和测试没发现的问题）。微服架构中，开发团队需要用做“产品”的态度来对待每一个微服务，持续关注服务运作情况，并不断分析来帮助用户改善业务功能。

​ 理解：微服务架构中对开发的要求是多元化的，多元化的技术人才将是未来的方向。在开发的过程中出现分歧时，需要有一个小组长职位的人（他需要懂沟通技巧及快速商定结果的方法），来决定此次事情怎么去做，或者怎么去验证，要有一个开放的心态去接受大家的批评和表扬（有则改之，无则加勉）。

智能端点与哑管道

​ 在单体服务中，组件之间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不再一个进程中，组件之间靠RPC方式调用，会导致微服务之间产生繁琐通信，是的系统表现更为复杂，所以需要更粗粒度的通信协议。
在微服务架构中，通常使用下面两种服务方式调用：
1）使用HTTP的RESTful API或轻量级的消息发送协议，实现信息传递与服务调用的触发。
2）通过轻量级消息总线上传递消息，类似RabbitMQ、kafka等一些提供可靠异步交换的中间件。

理解：微服务之间的调用，会出现“智能端点与哑管道”的特点，例如正常的微服务之间的调用是微服通过注册中心服务实例找到相应的服务，服务只需注册到服务中心即可，无须关注怎么调用，若横向扩展服务，直接部署服务即可，还有接口之间的数据转换，这是我理解智能端点；当服务之间调用的时，有服务发起到服务注册中心，注册中心到网关服务，在有网关配置规则找服务实例，在通过负载均衡规则去调度服务，整个传输过程只提供路由或者负载均衡之类的，不承载业务逻辑，或者是MQ之类的异步消息中间件，根本不关心具体传送的数据，这是我理解的“哑管道”；这个确实有点难理解，若谁有更好的理解可以发出来，大家好好讨论下。

去中心化 治理

​ 当时单体服务架构时，通常都是统一技术栈，因为每一种技术都有短板，这会导致碰到短板时，不得不花大力气去解决，并且可能因为底层原因解决的不好，最终成为系统的瓶颈。

​ 在微服务架构中，通过采用轻量级的契约定义接口，使得对于服务本身具有的技术平台不那么的敏感，这样整个服务架构系统中的各个组件就可以针对不同的业务特点选择不同的技术平台，终于不会出现杀鸡用牛刀或者杀牛用指甲刀的尴尬处境了。

​ 理解：不想单体服务的时候，技术单一，很多功能受限于技术的，现在服务与服务之间是用接口约定的，可以找到更适合业务场景的技术。

去中心化 管理数据

​ 在实施微服务架构时，我们都希望每一个服务来管理自由的数据库，这就是数据管理的去中心化。

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

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

​ 理解：这个和去中心化治理类似，让特殊业务场景的功能使用更合适的数据化，让并发大的服务单独存储在自己的数据库实例中，让服务更加稳定，防止一个功能把数据库锁死，而引起的整个系统崩塌。

基础设施自动化

​ 近些年来云计算和容器化技术不断成熟，运维基础设施的工作变得越来越容易。但是，当实施微服务架构时，数据库、应用程序的大小都变小了，但是数量成倍增长。这使得运维关注的内容成倍的增长，并且操作性任务也会成倍增长，这些问题若没有得到妥善解决，必将成为运维人员的噩梦。

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

理解：当服务增多时，运维的工作量增加了，但是同时出现问题的次数可能就增加了，所以需要一些自动化的操作来减少或者避免人工失误。

容错设计

​ 单体服务一旦一个功能出问题整个服务全部挂掉。而在微服务中，由于每个服务都是独立运行的，所以存在部分服务故障，而其他服务正常。为了减少服务的影响，在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的。通常，都希望每个服务中实现监控和日志记录的组件，例如服务状态、断路由状态、吞吐量、网络延迟等关键数据的仪表盘等。

演进式设计

​ 要实施一个完美的微服务架构，需要考虑的合计和成本不小，对于没有足够经验的团队来说，甚至要比单体服务付出更多的代价。
​ 在很多情况下，架构师都会以演进的方式进行系统构建。在初期以单体服务方式来设计和实施，一方面系统体量并不会很大，构建和维护的陈本都不高。另一方面初期的核心业务在后面不会发生巨大的改变。随着系统的发展或者业务的需要，会将一些经常变动或是有一定时间效应的内容进行微服务处理，并逐渐将原来在单体服务中多变的模块逐步拆分除开，而稳定不太变化的模块就形成一个核心服务存在于整个微服架构中。

4.为什么要用SpringCloud

​ 上面已经介绍微服务架构的优缺点，以及拆分以后带来的诸多问题，作为一个新手来说，准备实施微服务架构时，为了避免踩坑，我们不得不在核心问题上做出选择，而选择又是如此之多，这在技术选型初期，需要花费巨大的调研，分析与实验精力。

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

​ 如果你是一名高手，实施微服务架构都不是问题，然而千军易得、良将难求。而是用Spring Cloud来实施就像直接购买品牌技一样，在Spring 社区的整合之下，做了大量的兼容测试，保证了其拥有更好的稳定性，如果要在Spring Cloud 架构下使用使用非原装的组件时，就需要对其基础有足够的了解。

Spring Cloud 简介

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

​ Spring cloud 包含如下子项目：

• Spring Cloud Config :配置管理工具，支持使用git 存储配置美容，可以使用它实现应用哦诶之的外部存储，并且支持客户端配置信息刷新、加密/解密配置内容的等。
• Spring Cloud Netflix 核心组件，对多个Netflix OSS 开源套件进行整合。
  • Eureka ： 服务治理组件，包换服务注册中心、服务注册于发现机制的实现。
  • Hystrix:容错管理组件，实现断路由模式，帮助服务依赖中出现的延迟为故障提供强大的容错能力。
  • Ribbon：客户端负责均衡的服务调用组件。
  • feign:基于Robbon和Hystrix 的声明式调用组件。
  • Zuul:网关组件，提供智能路由、访问过滤等功能。
  • Archaius:外部化配置组件
• Spring Cloud Bus:事件、消息总线，用于传播集群中的状态变化或事件，已出发后续的处理，比如用来动态刷新配置等。
• Spring Cloud Cluster:针对ZooKeeper、Redis、Hazelcast、Consul的选举算法和通用状态模式的实现。
• Spring Cloud Cloudfoundry :与Privotal Cloudfoundry 的整合支持。
• Spring Cloud Consul:服务发下与配置管理工具。
• Spring Cloud Stream:通过Redis、Rabbit 或者kafka 实现消费服务，可以通过简单声明式模式来发送和接受消息。
• Spring Cloud AWS ：用于简化整合Amazon Web Service 的组件。
• Spring Cloud Security :安全工具包，提供Zuul 代理对OAuthor2客户端请求中继器。
• Spring Cloud Sleuth :Spring Cloud应用的分部署跟踪实现，可以完美整合Zipkin.
• Spring Cloud ZooKeeper:基于ZooKeeper 的服务发现与配置管理组件。
• Spring Cloud Starters:Spring Cloud 基础组件，它是基于 Spring Boot 风格项目的基础依赖模块。
• Spring Cloud CLI:用于在Groovy 中快速创建Spring Cloud 应用的Spring Cloud CLI插件 。
• 。。。。。。。。。。