SpringCloud系列一之微服务

微服务架构

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构。----Martin Fowler（马丁·福勒）

微服务的优劣

优点：

1. 每个服务足够内聚，足够小，可以聚焦指定业务功能。
2. 开发简单，开发效率提高。
3. 松耦合，无论在开发和部署时都是独立的。
4. 可以使用不同语言开发微服务。
5. 微服务可以灵活的集成自动化测试和自动化部署工具。

缺点：

1. 开发人员要处理分布式系统的复杂性，比如网络延迟，分布式事务，异步消息等。
2. 多服务造成运维的压力增加。
3. 接口的规范要更加完善，因为从单体系统中的代码依赖变为服务间的通信依赖。
4. 服务间的通信成本，数据一致性等问题

为什么是SpringCloud?

比较著名的微服务架构：阿里的dubbo,当当的dubbox,netflix的Eureka等，那么我们为什么选择SpringCloud呢？
刚刚列举的框架只是针对微服务的某一类问题进行解决，而SpringCloud则是解决微服务架构综合性解决框架，比如服务治理，容错，负载均衡，网关，时间总线等

SpringCloud的简介

简述：
SpringCloud是基于SpringBoot实现的微服务架构开发工具，它为微服务架构中设计的配置管理，服务治理，断路器，智能路由，控制总线，分布式会话，集群管理，提供了一种简单的开发方式。

组件：

• 独挑大梁类(独自启动不需要依赖其它组件)

  • Eureka，服务注册中心，特性有失效剔除、服务保护。
  • Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。
  • Zuul，API服务网关，功能有路由分发和过滤。
  • Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式。

• 润物无声类(融合在每个微服务中、依赖其它组件并为其提供服务)

  • Ribbon，客户端负载均衡，特性有区域亲和、重试机制。
  • Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。
  • Feign，声明式服务调用，本质上就是Ribbon+Hystrix。
  • Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。
  • Bus，消息总线，配合Config仓库修改的一种Stream实现。
  • Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。

组件实际用处

每个组件都不是平白无故的产生的，是为了解决某一特定的问题而存在。

1. Eureka和Ribbon，是最基础的组件，一个注册服务，一个消费服务。
2. Hystrix为了优化Ribbon、防止整个微服务架构因为某个服务节点的问题导致崩溃，是个保险丝的作用。
3. Dashboard给Hystrix统计和展示用的，而且监控服务节点的整体压力和健康情况。
4. Turbine是集群收集器，服务于Dashboard的。
5. Feign是方便我们程序员写更优美的代码的。
6. Zuul是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护的。
7. Config是为了解决所有微服务各自维护各自的配置，设置一个统一的配置中心，方便修改配置的。
8. Bus是因为config修改完配置后各个结点都要refresh才能生效实在太麻烦，所以交给bus来通知服务节点刷新配置的。
9. Stream是为了简化研发人员对MQ使用的复杂度，弱化MQ的差异性，达到程序和MQ松耦合。
10. Sleuth是因为单次请求在微服务节点中跳转无法追溯，解决任务链日志追踪问题的。