-de8bd8f33c3e44a59907dafe1884f228.png)
微服务概述
是什么
业界大牛 Martin Fowler 这样描述微服务：
参考【微服务(Microservices)-微服务原作者Martin Flower博客翻译】。
下面是关于上述博客中的部分重点总结：
-
就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style）。
-
但通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTFul API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。
技术维度理解：
- 微服务的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底的去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
微服务与微服务架构
-
微服务强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的看，可以看做 Eclipse 里面的一个个微服务工程或 Module。
-
微服务架构是一种架构模式或架构风格，如上总结。
微服务优缺点
优点
-每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求。
-开发简单、开发效率高，一个服务可能就是专一的只干一件事。
-微服务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成。
-微服务是松耦合的，是由功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
-微服务能使用不同的语言进行开发。
- 易于与第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如 Jenkins、Hudson、Bamboo。
- 微服务易于被一个开发人员理解、修改和维护，这样小团队更能关注自己的工作成果，无需通过合作也能体现价值。
- 微服务允许你利用融合最新技术。
- 微服务只是业务逻辑的代码，不会和 HTML、CSS 或其它 UI 组件混合。
- 每个微服务都可以有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
缺点
- 开发人员要处理分布式系统的复杂性。
- 多服务运维难度，随着服务的增加，运维的压力也在增大。
- 系统部署依赖。
- 服务间通信成本。
- 数据的一致性。
- 系统集成测试。
- 性能监控。
微服务技术栈
| 微服务条目 | 落地技术 |
|---|---|
| 服务开发 | SpringBoot、Spring、SpringMVC |
| 服务管理与配置 | Netflix 公司的 Archaius、阿里的 Diamond 等 |
| 服务注册于发现 | Eureka、Consul、Zookeeper等 |
| 服务调用 | Rest、RPC、gRPC |
| 服务熔断器 | Hystrix、Envoy 等 |
| 负载均衡 | Ribbon、Nginx 等 |
| 服务接口调用 | Feign 等 |
| 消息队列 | Kafka、RabbitMQ、ActiveMQ 等 |
| 服务配置中心管理 | SpringCloudConfig、Chef 等 |
| 服务路由（API 网关） | Zull 等 |
| 服务监控 | Zabbix、Nagios、Metrics、Spectator 等 |
| 全链路追踪 | Zipkin、Brave、Dapper 等 |
| 服务部署 | Docker、OpenStack、Kubernetes 等 |
| 数据流操作开发包 | SpringCloud Stream（封装与 Redis、Rabbit、Kafka 等发送接收消息） |
| 事件消息总线 | Spring Cloud Bus |
Eureka VS Zookeeper
作为服务注册中心，Eureka 比 Zookeeper 好在哪里？
著名的 CAP 理论指出，一个分布式系统不可能同时满足 C（一致性）、A（可用性）和 P（分区容错性）。由于分区容错性 P 是在分布式系统中必须保证的，因此我们只能在 A 和 C 之间权衡。
因此 Zookeeper 保证的是 CP，而 Eureka 则是保证 AP。
Zookeeper 保证 CP:
- 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是 Zookeeper 会出现这样一种情况，当 master 节点因为网络故障与其它节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长（30 - 120s），且选举期间整个 Zookeeper 集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得 Zookeeper 失去 master 节点是较大概率会发生的事，虽然服务在最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka 保证 AP：
- Eureka 看明白了这一点，因此在设计时就优先保证可用性。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余节点依然可以提供注册和查询服务。而 Eureka 的客户端在向某个 Eureka 注册师如果发现连接失败，则会自动切换至其它节点，只要有一台 Eureka 服务还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka 还有一种自我保护机制，如果在 15 分钟内超过 85% 的节点都没有正常的心跳，那么 Eureka 就认为客户端与注册中心出现了网络故障，此时就会出现如下几种情况：
- Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
- Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）。
- 当网络稳定时，当前实例新的注册信息会被同步到其它节点中。
因此，Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会向 Zookeeper 那样使整个注册服务瘫痪。
使用 SpringCloud 的原因
选型依据
- 整体解决方案和框架成熟度
- 社区热度
- 可维护性
- 学习曲线
主流微服务架构
- 阿里 Dubbo、HSF
- 京东 JSF
- 新浪微博 Motan
- 当当网 Dubbox
微服务框架对比
| 功能点/服务框架 | Netflix/SpringCloud | Motan | gRPC | Thrift | Dubbo/DubboX |
|---|---|---|---|---|---|
| 功能定位 | 完整的微服务框架 | RPC 框架，但整合了 ZK 或 Consul，实现集群环境的基本的服务注册/发现 | RPC 框架 | RPC 框架 | 服务框架 |
| 支持 Rest | 是，Ribbon 支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
| 支持 RPC | 否 | 是（Hession2） | 是 | 是 | 是 |
| 支持多语言 | 是 | 否 | 是 | 是 | 否 |
| 服务注册/发现 | 是（Eureka），Eureka 服务注册表，Karyon 服务端框架支持服务自注册和健康检查 | 是（Zookeeper/Consul） | 否 | 否 | 是 |
| 负载均衡 | 是（服务端 Zuul + 客户端 Ribbon）。Zuul：服务、动态路由、云端负载均衡；Eureka：针对中间层服务器 | 是（客户端） | 否 | 否 | 是（客户端） |
| 配置服务 | Netflix Archaius，SpringCloud Config Server 集中配置 | 是（Zookeeper 提供） | 否 | 否 | 否 |
| 服务调用链监控 | 是（Zuul），Zuul 提供边缘服务，API 网关 | 否 | 否 | 否 | 否 |
| 高可用/容错 | 是（服务端 Hystrix + 客户端 Ribbon） | 是（客户端） | 否 | 否 | 是（客户端） |
| 典型应用案例 | Netflix | Sina | |||
| 社区活跃程度 | 高 | 一般 | 高 | 一般 | 一般 |
| 文档丰富度 | 高 | 一般 | 一般 | 一般 | 高 |
| 其它 | SpringCloud Bus 为我们的应用程序带来了更多管理端点 | 支持降级 | Netflix 内部在开发继承 gRPC | IDL 定义 | 实践的公司比较多 |
SpringCloud 介绍
概述
在 Spring 官网是这样描述 SpringCloud 的：
COORDINATE ANYTHING: DISTRIBUTED SYSTEMS SIMPLIFIED
Building distributed systems doesn't need to be complex and error-prone. Spring Cloud offers a simple and accessible programming model to the most common distributed system patterns, helping developers build resilient, reliable, and coordinated applications. Spring Cloud is built on top of Spring Boot, making it easy for developers to get started and become productive quickly.
协调一切：简化分布式系统
没有复杂和出错地构建分布式系统。Spring Cloud 为最常见的分布式系统模式提供了一种简单易用的编程模型，可帮助开发人员构建弹性，可靠和协调的应用程序。SpringCloud 构建于 SpringBoot 之上，使开发人员可以轻松入门并快速提高工作效率。
SpringCloud，基于 SpringBoot 提供了一套微服务解决方案，包括服务注册与发现、配置中心、全链路监控、服务网关、负载均衡、熔断器等组件，除了基于 NetFlix 的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。
SpringCloud 利用 SpringBoot 的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等，它们都可以用 SpringBoot 的开发风格做到一键启动和部署。
SpringBoot 并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过 SpringBoot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
总结上述，SpringCloud 就是分布式微服务架构下的额一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。
SpringCloud VS SpringBoot
SpringBoot 专注于快速方便的开发单个个体微服务，可以离开 SpringCloud 独立使用开发项目。
SpringCloud 是关注全局的微服务协调整理治理框架，它将 SpringBoot 开发的一个个单体微服务整理并管理起来，为各个微服务之间提供配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。SpringCloud 离不开 SpringBoot，属于依赖的关系。
总结上述：SpringBoot 专注于快速、方便的开发单个微服务个体，而 SpringCloud 是关注全局的服务治理框架。
SpringCloud VS Dubbo
| Dubbo | SpringCloud | |
|---|---|---|
| 服务注册中心 | Zookeeper | SpringCloud Netflix Eureka |
| 服务调用方式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | SpringBoot Admin |
| 断路器 | 不完善 | SpringCloud Netflix Hystrix |
| 服务网关 | 无 | SpringCloud Netflix Zuul |
| 分布式配置 | 无 | SpringCloud Config |
| 服务跟踪 | 无 | SpringCloud Sleuth |
| 消息总线 | 无 | SpringCloud Bus |
| 数据流 | 无 | SpringCloud Stream |
| 批量任务 | 无 | SpringCloud Task |
| ... | ... | ... |
最大区别：SpringCloud 抛弃了 Dubbo 的 RPC 通信，采用的是基于 HTTP 的 REST 方式。
严格来说，这两种方式各有优劣。虽然从一定程度上来说，SpringCloud 牺牲了服务调用的性能，但也避免了上面提到的原生 RPC 带来的问题。而且 REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。
用品牌机与组装机的区别为例说明：
- 很明显，SpringCloud 的功能比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的拳头项目，它也能够与 SpringFramework、SpringBoot、SpringData、SpringBatch 等其它 Spring 项目完美融合，这些对于微服务而言是至关重要的。使用 Dubbo 构建的微服务架构就像组装电脑，各环节我们选择的自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而 SpringCloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要使用非原装组件以外的东西，就需要对其基础底层有足够的了解。
社区支持和更新力度：
- 最为重要的是，Dubbo 停止了 5 年左右的更新，虽然 2017 年 7 月重启了。对于技术发展的新需求，需要由开发者自行脱战升级（比如当当网弄出了DubboX），这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能力去修改 Dubbo 源码及周边的一整套解决方案。
下面是 Dubbo 重启维护开发的主要负责人之一刘军对 Dubbo 及 SpringCloud 的关系阐述：
刘军，阿里巴巴中间件高级研发工程师，主导了 Dubbo 重启维护后的几个发版计划，专注于高性能 RPC 框架和微服务相关领域。层负责网易考拉 RPC 框架的研发及指导在内部使用，参与了服务治理平台、分布式跟踪系统、分布式一致性框架等从无到有的设计与开发过程。
问：目前 Dubbo 被拿来比较的最多的就是 SpringCloud，您怎么看待二者的关系，业务上是否有所冲突？
答：关于 Dubbo 和 SpringCloud 间的关系，我们在开源中国年终盛典的 Dubbo 分享中也作了简单阐述，首先要明确的一点是 Dubbo 和 SpringCloud 并不是完全的竞争关系，两者所解决的问题域并不一样：Dubbo 的定位始终是一款 RPC 框架，而 SpringCloud 的目标是微服务架构下的一站式解决方案。如果非要比较的话，我觉得 Dubbo 可以类比到 Netflix OSS 技术栈，而 SpringCloud 继承了 Netflix OSS 作为分布式服务治理解决方案，但除此之外 SpringCloud 还提供了包括 config、stream、security、sleuth 等等分不是问题解决方案。当前由于 RPC 协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时 Dubbo 与 SpringCloud 是只能二选一，这也是为什么大家总是拿 Dubbo 和 SpringCloud 做对比的原因之一。Dubbo 之后会积极寻求适配到 SpringCloud 生态，比如作为 SpringCloud 的二进制通信方案来发挥 Dubbo 的性能优势，或者 Dubbo 通过模块化以及对 http 的支持适配到 SpringCloud。
SpringCloud 相关资料及社区
- 官网：https://spring.io/projects/spring-cloud
- 官方文档：https://cloud.spring.io/spring-cloud-static/Dalston.SR5/single/spring-cloud.html
- 官方文档中文版：https://springcloud.cc/spring-cloud-dalston.html
- SpringCloud Netflix 中文文档：https://springcloud.cc/spring-cloud-netflix.html
- SpringCloud 中国社区：http://springcloud.cn/
- SpringCloud 中文网：https://springcloud.cc/
评论区