回顾
架构分类
单体架构
-
单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署。
-
优点:
- 架构简单
- 部署成本低
-
缺点:
- 耦合度高(维护困难、升级困难)
- 耦合度高(维护困难、升级困难)
分布式架构
-
分布式架构:根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发,称为一个服务。
-
优点:
- 降低服务耦合
- 有利于服务升级和拓展
-
缺点:
- 服务调用关系错综复杂
- 服务调用关系错综复杂
-
分布式架构虽然降低了服务耦合,但是服务拆分时也有很多问题需要思考:
- 服务拆分的粒度如何界定?
- 服务之间如何调用?
- 服务的调用关系如何管理?
人们需要制定一套行之有效的标准来约束分布式架构。
微服务架构
什么是微服务
- 微服务的概念源于2014年3月Martin Fowler(马丁·福勒)所写的一篇文章:https://martinfowler.com/microservices。
- 微服务架构风格是一种将一个单体应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常是基于HTTP协议的RESTful API)。这些服务围绕业务能力构建,并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。
优点
- 逻辑清晰,项目复杂度降低:通过对共享业务更加细粒度的拆分,一个服务只需要关注一个特定的业务领域,并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低,开发、维护会更加简单;
- 技术选型更加灵活:每个微服务都有不同的团队来维护,所以可以结合业务特性自由选择技术栈;
- 可扩展性更强:可以根据每个微服务的性能要求和业务特点对服务进行灵活扩展;
- 独立部署:单个微服务的代码量比较小,使得发布更加高效;
- 容错性:如果某一个服务发生故障,可以通过重试、降级等机制实现容错;
缺点
- 性能降低,微服务的间通过REST、RPC等形式进行交互,通信的延时会受到较大的影响;
- 提升了运维的难度(版本发布、问题排查、配置管理、监控);
- 数据一致性的问题;
微服务的架构特征:
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责
- 自治:团队独立、技术独立、数据独立,独立部署和交付
- 面向服务:服务提供统一标准的接口,与语言和技术无关
- 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题
微服务的上述特性其实是在给分布式架构制定一个标准,进一步降低服务之间的耦合度,提供服务的独立性和灵活性。做到高内聚,低耦合。
因此,可以认为微服务是一种经过良好架构设计的分布式架构方案 。
微服务架构面临的挑战
- 微服务粒度大小难以划分,需要设计人员对业务有很好的掌握;
- 分布式复杂性,主要体现在分布式事务、网络延迟、系统容错等问题解决难度较大;
- 微服务之间通信成本较高,对微服务之间网络稳定性、通信速度要求较高;
- 由于微服务数量较大,运维人员运维、部署有较大的挑战
技术挑战
- 微服务架构的主要目的是实现业务服务的解耦;
- 对服务进行治理(服务的注册与发现、服务与服务之间的调用、熔断限流、负载均衡、链路追踪、分布式配置中心、服务路由等);