微服务之初识Spring Cloud（一）

什么是微服务？

微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”。微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
开发原则：高内聚低耦合。

微服务的优势

• 复杂度可控：

在将应用分解的同时，规避了原本复杂度无止境的积累。每一个 微服务专注于单一功能，并通过定义良好的接口清晰表述 服务边 界。由于体积小、复杂度低，每个微服务可由一个小规模开发团 队完全掌控，易于保持高可维护性和开发效率。

• 独立部署：

由于微服务具备独立的运行进程，所以每个微服务也可以独立部 署。当某个微服务发生变更时无需编译、部署整个应用。由微服 务组成的应用相当于具备一系列可并行的发布流程，使得发布更 加高效，同时降低对生产环境所造成的风险，最终缩短应用交付 周期。

• 技术选型灵活：

微服务架构下，技术选型是去中心化的。每个团队可以根据自身 服务的需求和行业发展的现状，自由选择最适合的技术栈。由于 每个微服务相对简单，故需要对技术栈进行升级时所面临的风险 就较低，甚至完全重构一个微服务也是可行的。

• 容错：

当某一组建发生故障时，在单一进程的传统架构下，故障很有可 能在进程内扩散，形成应用全局性的不可用。在微服务架构下， 故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、 平稳退化等机制实现应用层面的容错。

• 扩展:

单块架构应用也可以实现横向扩展，就是将整个应用完整的复制 到不同的节点。当应用的不同组件在扩展需求上存在差异时，微 服务架构便体现出其灵活性，因为每个服务可以根据实际需求独 立进行扩展。

微服务架构示例

图片来源网络

传统开发与微服务的区别

1. 分工不同
   传统我们可能是一个一个模块，现在可能是一人一个系统。
2. 架构不同
   服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大。
3. 部署方法不同
   如果还像以前一样部署估计累死了，自动化运维不可不上。
4. 容灾不同
   好的微服务可以隔离故障避免服务整体down掉，坏的微服务设计仍然可以因 为一个子服务出现问题导致连锁反应。

spring cloud

官方地址：Spring Cloud
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

核心组件

1. 服务发现——Netflix Eureka
   服务治理是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册、发现和管理。Spring Cloud Eureka就是这样一个服务治理框架
2. 客服端负载均衡——Netflix Ribbon
   Ribbon，主要提供客户侧的软件负载均衡算法。
   Ribbon客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。
3. 断路器——Netflix Hystrix
   断路器可以防止一个应用程序多次试图执行一个操作，即很可能失败，允许它继续而不等待故障恢复或者浪费 CPU 周期，而它确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决。如果问题似乎已经得到纠正，应用程序可以尝试调用操作。断路器增加了稳定性和灵活性，以一个系统，提供稳定性，而系统从故障中恢复，并尽量减少此故障的对性能的影响。它可以帮助快速地拒绝对一个操作，即很可能失败，而不是等待操作超时（或者不返回）的请求，以保持系统的响应时间。如果断路器提高每次改变状态的时间的事件，该信息可以被用来监测由断路器保护系统的部件的健康状况，或以提醒管理员当断路器跳闸，以在打开状态。
4. 服务网关——Netflix Zuul
   为了解决多次请求访问不同微服务，请求不统一增加了客户端的复杂度和暴露了服务器IP+端口号容易遭受到攻击行为等问题，springcloud同样继承了Zuul网关；类似nginx，Zuul也支持反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。
5. 分布式配置——Spring Cloud Config
   这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。

架构流程

图片来源于网络

通过这张图，我们来了解一下各组件配置使用运行流程：

1.请求统一通过API网关（Zuul）来访问内部服务.
2.网关接收到请求后，从注册中心（Eureka）获取可用服务
3.由Ribbon进行均衡负载后，分发到后端具体实例
4.微服务之间通过Feign进行通信处理业务
5.Hystrix负责处理服务超时熔断
Turbine监控服务间的调用和熔断相关指标

说明

我也是个刚接触微服务架构的小白，这篇帖子也是看了网上的许多文章以后加以我自己的理解，最终才写下来的。以前也写过有个spring cloud的一个小demo，下篇帖子我就来写一写如何初步搭建微服务架构。

本人才疏学浅，若有写错的地方，欢迎指正哦！