什么是微服务，为什么是微服务，什么是springCloud

我们都一直说单体应用，分布式，微服务；在技术路线上我们都经历或大或小的技术改革，技术架构的演变，常见的有：单体应用，集群应用（部署多个单体应用），分布式结构，soa架构(俗称服务化，也就是常说的面向接口开发)，微服务架构

近几年来，随着互联网的发展，对于软件交付与迭代速度和效率的要求不断提高，技术更新不断提升，微服务凭借灵活扩展，独立部署等优势，成为了分布式架构中的主流。任何应用主体中，业务初期都是很简单，通常我们都会用单体应用去实现，不断的随着公司业务的逐步扩张发展，产品思想也变的越来越复杂，单体应用的弊端就会凸显；单体结构的应用随着系统的复杂度增高，会暴露出来各种问题：

单体应用复杂：虽然在规范的开发文档和通过组件化把单体应用划分成多个单元，降低每个单元的复杂度，但在实际开发中，组件化的效果不是很好。主要是由于公共代码的使用，公共代码被多个组件使用的情况下，很难在做一些更新，其次开发人员的自我修养的或能力不行的情况下造成每h个单元直接的接口不明确，组件直接随便引用，导致依赖错综复杂。

开发速度慢：当应用变得复杂的情况下，开发人员需要在理解需求的情况下需要花更多的时间去理解原来的代码，并且需要评估改动带来的潜在影响。做过单体开发的人员会经常遇到，看似一个很小的改动，可能会导致很严重的影响。慢慢的开发人员也就不愿意再去改进原有的代码质量，每个人都是重写一套，随着代码量增加，项目启动，编译时间也会增加，导致很多时间都在无意义的等待中。

可扩展性差：尤其在现有极速发展情况下，公司业务拓展很快的情况下，应用的处理能力不能满足业务需求时，需要进行扩展；我们一般会采取两种扩展手段，一种是垂直扩展也就是增加单个应用实例可使用的资源，但是针对不同的组件需要的资源又不相同，组件之间的需求不一致，有些需要cpu有些需要内存；还有一种就是水平扩展也就是增加应用实例的数量，但是会存在无法有效分配资源。

迭代速度慢：随着互联网的发展，对于软件交付与迭代速度和效率的要求不断提高，应用需要以最快的速度添加新功能和修复bug，而且有可能业务随时会产生变化，单体应用由于体型庞大，复杂度高，每一次的开发，编译，测试等持续集成中花费时间久，限制了更新频率。

稳定性差：不同业务使用同一应用，同一进程，组件直接缺少隔离性，无论那个组件中出现问题，都会导致整个应用的崩溃，或者由于某个组件占用大量资源从而导致其他组件资源不足而宕机。

技术栈更新困难：单体应用一般来说技术栈单一，包括开发语言，框架，数据库等需要所有开发人员掌握相同技术栈，但是针对现在业务快速扩展的情况下，不同的业务可能会需要不同的技术栈来满足不同的需求。但是在单一应用中想要使用不同的技术栈是很困难的，从而导致应用系统的技术栈不断老化

近些年来，微服务框架逐步取代了单体框架，这是大势所趋。

一、什么是微服务架构

微服务架构是在SOA之后的一种更加低耦合的一种架构，在现有的业界中对于微服务没有统一的标准的定义。通常来说，微服务架构是一种架构模式、一种架构风格，提倡将单一的程序划分成不同的小服务，每个服务都是一个进程，服务之间相互调用，相互配置。服务间也采用轻量级的通信机制，每个服务都能够被独立编译，打包，部署。同时根据业务也可选择不通数据存储。微服务的核心就是将传统的一站式的应用，根据业务拆成一个个不同的服务，彻底解耦，每个服务都提供不同的业务功能，每个服务都只做自己的事，拥有自己独立的数据库，可以单独部署；微服务强调服务的大小，它关注的是某一个点，具体解决某一个问题。

1、微服务架构图

2、优缺点 

优点：

• 足够聚焦：聚焦指定的业务需求和功能，足够小，更容易理解
• 专一：一个服务只干一件事
• 开发要求低：每个服务可以被小团队独立开发
• 松耦合：无论是在开发阶段还是部署阶段都是独立的
• 语音无要求：不同服务可以选择不同的技术栈
• 维护成本低：小团队维护
• 技术更新简单：更容易融合新技术
• 存储：可以有独立的存储能力，也可以统一存储
• 互不影响：某一个服务宕机，也不会影响其他服务

缺点：

• 复杂性：分布式带来的复杂性
• 运维难度：有些业务往往会跨好几个服务，运维压力增加
• 通信成本：服务间通信成本

3、微服务技术栈

服务开发	Spring Boot、Spring、Spring MVC
服务配置与管理	Netflix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Consul、Zookeeper等
服务调用	Rest、RPC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用(客户端调用服务的简化工具)	Feign等
消息队列	Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理	Spring Cloud Config、Chef等
服务路由（API网关）	Zuul等
服务监控	Zabbix、Nagios、Metrics、Spectator等
全链路追踪	Zipkin，Brave、Dapper等
服务部署	Docker、OpenStack、Kubernetes等
数据流操作开发包	Spring Cloud Stream（封装与Redis,Rabbit、Kafka等发送接收消息）
事件消息总线	Spring Cloud Bus
…	…

二、什么是springCloud

springCloud是一系列框架的有序集合，它利用springboot的开发便利简化了分布式系统基础设施的开发：服务注册发现，配置中心，路由，消息总线，负载均衡，断路由，数据监控等。都可以使用springBoot的开发风格做到一键启动和部署。springCloud是将各家公司开发的比较成熟的，经得起考验的服务框架组合起来，利用springBoot风格再封装，屏蔽掉复杂的配置和实现原理，最终提供了一套简单易懂，易部署和易维护的分布式系统开发工具包。

1、springCloud整体架构图

2、主要功能项目（a.对现有比较成熟springBoot的封装和抽象类项目；b.分布式系统的技术设施的实现）

2.1、Sping Cloud Config

集中配置管理工具、统一的外部配置管理，默认使用git来存储配置，可以支持客户端配置的刷新及加密，解密操作

2.2、Spring Cloud Netflix

Netflix OSS 开源组件：主要包括Eureka、Hystirx、Ribbon、Feign、Zuul等核心组件

• Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
• Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
• Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
• Feign：基于Ribbon和Hystrix的声明式服务调用组件；
• Zuul：API网关组件，对请求提供路由及过滤功能。

2.3、Spring Cloud Bus

用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置。

2.4、Spring Cloud Consul

基于Hashicorp Consul的服务治理组件。

2.5、Spring Cloud Security

安全工具包，对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。

2.6、Spring Cloud Sleuth

Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。

2.7、Spring Cloud Stream

轻量级事件驱动微服务框架，可以使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka及RabbitMQ。

2.8、Spring Cloud Task

用于快速构建短暂、有限数据处理任务的微服务框架，用于向应用中添加功能性和非功能性的特性。

2.9、Spring Cloud Zookeeper

基于Apache Zookeeper的服务治理组件。

2.10、Spring Cloud Gateway

API网关组件，对请求提供路由及过滤功能。

2.11、Spring Cloud OpenFeign

基于Ribbon和Hystrix的声明式服务调用组件，可以动态创建基于Spring MVC注解的接口实现用于服务调用。

3、和SpringBoot的关系

• Spring Boot 是 Spring 的一套快速配置脚手架，可以基于Spring Boot 快速开发单个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具。Spring -> Spring Boot > Spring Cloud 这样的关系。
• Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring Boot，属于依赖的关系
• Spring Boot专注于快速、方便集成的单个个体微服务，Spring Cloud是关注全局的服务治理框架
• Spring Boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring Boot来实现，可以不基于Spring Boot吗？不可以

---

下一篇：从一个简单的springCloud项目开始—搭建一个微服务框架