微服务概要

微服务概要

什么是微服务

1. 微：体积小，单个服务设计到运维人数少。

2. 服务：区别于系统，服务一个或一组相对较小且独立的功能单元。用户可感知的最小功能集。（类似于插件？）

   ​ 微服务架构是一种使用一套小服务开发单个应用的方式途径，每个服务运行在自己的进程中，之间使用轻量级机制通信（HTTP API）。服务基于业务能力构建，通过自动化部署机制独立部署。采用不同的编程语言，不同的数据存储技术实现，保持最低限度的集中式管理。

为什么要微服务

独立系统的缺点

1. 扩展性差，可靠性不高，维护成本高。

2. 引入SOA服务化后，与某种技术栈强绑定（e.g J2EE）导致切换时间长，成本高

3. 在单体架构扩大过程时暴露以下主要问题：

   3.1. 复杂性逐渐变高（代码量大，模块之间区别模糊，逻辑混乱）

   3.2. 技术债务^[1]（ppy提到过）（人员流动导致技术债务增加）

   3.3. 部署速度逐渐变慢（代码量庞大，启动时间增加导致开发时间减少）

   3.4. 阻碍技术创新（老架构转向新技术的成本巨大）

   3.5. 无法按需伸缩（所有模块在一个框架下导致修改一个模块必须考虑其它的模块）

   技术债务是现在增加的任何代码，都将在以后，花费更多的时间，来处理它带来的问题。--通常是为了实现快速收益。

   ​

微服务与单体架构的区别

1. 单体架构所有模块耦合，代码量大，维护困难。微服务每个模块相当于一个单独的项目，代码量明显减少，问题相对容易解决。
2. 单体架构所有模块使用一个数据库，存储方式单一。微服务每个模块可使用不同的存储方式，单个模块对应自己的数据库。
3. 单体架构所有模块开发所使用技术相同，微服务模块每个模块都可以使用不同的开发技术，开发模式灵活

微服务与SOA区别

微服务本质上还是SOA架构，内涵有所不同，微服务不绑定某种特定技术，在一个微服务系统中，可以有不同语言编写的服务，它们靠Restful架构统一成一个系统，微服务与具体技术实现无关，扩展性强。

微服务本质

微服务关键在于系统提供一套基础的架构，可以让微服务独立部署、运行、升级，微服务之间在结构上松耦合，在功能上是一个统一的整体。

微服务的目的是有效的拆分应用，实现敏捷开发和部署。

微服务提倡团队间应该是inter-operate, not integrate，inter-operate是定义好系统边界和接口，在一个团队中全栈，团队自治，将每个团队的沟通成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合变弱，跨系统的沟通成本降低。

什么项目适合微服务

四要素

• 小：体积小，参加人员少
• 独：能够独立部署和运行
• 轻：使用轻量级的通信机制和架构
• 松：服务之间是松耦合的

微服务的设计

微服务设计原则

• 单一职责原则：每个微服务只需要实现自己的业务逻辑
• 服务自治原则：每个微服务开发、测试、运维都是独立的，包括数据库也是独立的，自己有一套完整的流程，不必依赖于其他模块。
• 轻量级通信原则：① 通信语言轻量；② 通信方式需要跨语言、跨平台的（让每个微服务都有足够的独立性，可以不受技术的牵制）
• 接口明确原则：微服务之间可能存在调用关系，为尽量避免接口变化而导致其他微服务调整，让接口尽量更通用、灵活，从而避免其他模块调整。

微服务优势与缺点

特性

• 每个微服务可独立运行在自己的进程中
• 一系列独立运行的微服务共同构建整个系统
• 每个服务作为独立业务开发，一个微服务一般完成某个特定功能
• 微服务之间通过轻量级的通信机制通信

特点

• 易于开发和维护
• 启动较快
• 局部修改容易部署
• 技术栈不受限
• 按需伸缩

缺点

• 运维要求较高：项目由多个微服务构成，每个模块出现问题都会导致整个项目异常，找出问题模块难度大。
• 分布式的复杂性
• 接口调整成本高：如果一个接口被多个服务调用，该接口变化时，所有依赖它的服务都必须调整。
• 重复劳动：一个微服务的工具类不能被其他微服务直接调用，不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

Spring Cloud 和 Spring Boot 区别

• Spring Cloud：微服务工具包，为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包
• Spring Boot：旨在简化创建产品级的Spring应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能，可以和spring cloud联合部署。

---

1. 技术债务是现在增加的任何代码，都将在以后，花费更多的时间，来处理它带来的问题。--通常是为了实现快速收益。参考 ↩