微服务概要
微服务概要
什么是微服务
-
微：体积小，单个服务设计到运维人数少。
-
服务：区别于系统，服务一个或一组相对较小且独立的功能单元。用户可感知的最小功能集。（类似于插件？）
微服务架构是一种使用一套小服务开发单个应用的方式途径，每个服务运行在自己的进程中，之间使用轻量级机制通信（HTTP API）。服务基于业务能力构建，通过自动化部署机制独立部署。采用不同的编程语言，不同的数据存储技术实现，保持最低限度的集中式管理。
为什么要微服务
独立系统的缺点
-
扩展性差，可靠性不高，维护成本高。
-
引入SOA服务化后，与某种技术栈强绑定（e.g J2EE）导致切换时间长，成本高
-
在单体架构扩大过程时暴露以下主要问题：
3.1. 复杂性逐渐变高（代码量大，模块之间区别模糊，逻辑混乱）
3.2. 技术债务[1]（ppy提到过）（人员流动导致技术债务增加）
3.3. 部署速度逐渐变慢（代码量庞大，启动时间增加导致开发时间减少）
3.4. 阻碍技术创新（老架构转向新技术的成本巨大）
3.5. 无法按需伸缩（所有模块在一个框架下导致修改一个模块必须考虑其它的模块）
技术债务是现在增加的任何代码，都将在以后，花费更多的时间，来处理它带来的问题。--通常是为了实现快速收益。
微服务与单体架构的区别
- 单体架构所有模块耦合，代码量大，维护困难。微服务每个模块相当于一个单独的项目，代码量明显减少，问题相对容易解决。
- 单体架构所有模块使用一个数据库，存储方式单一。微服务每个模块可使用不同的存储方式，单个模块对应自己的数据库。
- 单体架构所有模块开发所使用技术相同，微服务模块每个模块都可以使用不同的开发技术，开发模式灵活
微服务与SOA区别
微服务本质上还是SOA架构，内涵有所不同，微服务不绑定某种特定技术，在一个微服务系统中，可以有不同语言编写的服务，它们靠Restful架构统一成一个系统，微服务与具体技术实现无关，扩展性强。
微服务本质
微服务关键在于系统提供一套基础的架构，可以让微服务独立部署、运行、升级，微服务之间在结构上松耦合，在功能上是一个统一的整体。
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
微服务提倡团队间应该是inter-operate, not integrate，inter-operate是定义好系统边界和接口，在一个团队中全栈，团队自治，将每个团队的沟通成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合变弱，跨系统的沟通成本降低。
什么项目适合微服务
四要素
- 小：体积小，参加人员少
- 独：能够独立部署和运行
- 轻：使用轻量级的通信机制和架构
- 松：服务之间是松耦合的
微服务的设计
微服务设计原则
- 单一职责原则：每个微服务只需要实现自己的业务逻辑
- 服务自治原则：每个微服务开发、测试、运维都是独立的，包括数据库也是独立的，自己有一套完整的流程，不必依赖于其他模块。
- 轻量级通信原则：① 通信语言轻量；② 通信方式需要跨语言、跨平台的（让每个微服务都有足够的独立性，可以不受技术的牵制）
- 接口明确原则：微服务之间可能存在调用关系，为尽量避免接口变化而导致其他微服务调整，让接口尽量更通用、灵活，从而避免其他模块调整。
微服务优势与缺点
特性
- 每个微服务可独立运行在自己的进程中
- 一系列独立运行的微服务共同构建整个系统
- 每个服务作为独立业务开发，一个微服务一般完成某个特定功能
- 微服务之间通过轻量级的通信机制通信
特点
- 易于开发和维护
- 启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩
缺点
- 运维要求较高：项目由多个微服务构成，每个模块出现问题都会导致整个项目异常，找出问题模块难度大。
- 分布式的复杂性
- 接口调整成本高：如果一个接口被多个服务调用，该接口变化时，所有依赖它的服务都必须调整。
- 重复劳动：一个微服务的工具类不能被其他微服务直接调用，不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。
Spring Cloud 和 Spring Boot 区别
- Spring Cloud：微服务工具包，为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包
- Spring Boot：旨在简化创建产品级的Spring应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能，可以和spring cloud联合部署。
