微服务
-
Martin Fowler 在 2014年提出 Microservices架构
-
微服务是一种架构风格,将单体应用划分为小型的服务单元。
-
微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式。
- 每个服务运行在自己的进程中
- 服务间采用轻量级的方式进行通信(通常是HTTP API)
- 这些服务是基于业务逻辑和范围,通过自动化部署的机制来独立部署的,并且服务的集中管理应该是最低限度的,即每个服务可以采用不同的编程语言编写,使用不同的数据存储技术。
-
优点:
- 独立部署。不依赖其他服务,耦合性低,不用管其他服务的部署对自己的影响。
- 易于开发和维护。关注特定业务,所以业务清晰,代码量少,模块变的易开发、易理解、易维护。
- 启动快。功能少,代码少,所以启动快,有需要停机维护的服务,不会长时间暂停服务。
- 局部修改容易。只需要部署 相应的服务即可,适合敏捷开发。
- 技术栈不受限。java,node.js,go 等
- 按需伸缩.某个服务受限,可以按需增加内存,cpu 等。
- 职责专一。专门团队负责专门业务,有利于团队分工。
- 代码复用。不需要重复写。底层实现通过接口方式提供。
- 便于团队协作:每个团队只需要提供 API 就行,定义好 API 后,可以并行开发。
- 缺点:
- 分布式固有的复杂性。容错,网络延时,调用关系、分布式事务等,都会带来复杂。
- 分布式事务的挑战。每个服务有自己的数据库,有点在于不同服务可以选择适合自身业务的数据库。订单用MySQL,评论用Mongodb等。目前最理想解决方案是:柔性事务的最终一致性。
- 接口调整成本高。改一个接口,调用方都要改。
- 测试难度提升。一个接口改变,所有调用方都得测。自动化测试就变得重要了,API文档的管理也尤为重要。
- 运维要求高。需要维护几十上百个服务,监控变的复杂,并且还要关注多个集群。
- 重复工作。比如 java 的工具类可以在共享 common.ja r中,但在多语言下行不通,C++ 无法直接用 java的 jar 包。
微服务组件
基于微服务的特性,微服务的组件不局限于技术的实现。主要的组件有:
- 服务注册与发现:服务提供方将己方调用地址注册到服务注册中心,让服务调用方能够方便地找到自己;服务调用方从服务注册中心找到自己需要调用的服务的地址。
- 负载均衡:服务提供方一般以多实例的形式提供服务,负载均衡功能能够让服务调用方连接到合适的服务节点。并且,服务节点选择的过程对服务调用方来说是透明的。
- 服务网关:服务网关是服务调用的唯一入口,可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
- 配置中心:将本地化的配置信息(Properties、XML、YAML等形式)注册到配置中心,实现程序包在开发、测试、生产环境中的无差别性,方便程序包的迁移,也是无状态特性。
- 集成框架:微服务组件都以职责单一的程序包对外提供服务,集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下,让用户能够在统一的界面中使用系统。Spring Cloud 就是一个集成框架。
- 调用链监控:记录完成一次请求的先后衔接和调用关系,并将这种串行或并行的调用关系展示出来。在系统出错时,可以方便地找到出错点。
- 支撑平台:系统微服务化后,各个业务模块经过拆分变得更加细化,系统的部署、运维、监控等都比单体应用架构更加复杂,这就需要将大部分的工作自动化。现在,Docker 等工具可以给微服务架构的部署带来较多的便利,例如持续集成、蓝绿发布、健康检查、性能监控等等。如果没有合适的支撑平台或工具,微服务架构就无法发挥它最大的功效。
常见的架构图
Spring Cloud
Spring Cloud 是实现微服务架构的一系列框架的有机集合。是在 Spring Boot 基础上构建的,用于简化分布式系统构建的工具集。是拥有众多子项目的项目集合。利用 Spring Boot 的开发便利性,巧妙地简化了分布式系统基础设施(服务注册与发现、熔断机制、网关路由、配置中心、消息总线、负载均衡、链路追踪等)的开发。
原文
http://webfuse.cn/2020/04/22/从0开始用SpringCloud搭建微服务系统【一】/