微服务实践

最新推荐文章于 2025-03-17 20:16:59 发布

yolo_sec

最新推荐文章于 2025-03-17 20:16:59 发布

阅读量521

点赞数

分类专栏：学架构摘要文章标签：微服务 microservices

本文链接：https://blog.youkuaiyun.com/m0_60725291/article/details/122697632

版权

学架构摘要专栏收录该内容

37 篇文章

订阅专栏

方法篇

服务粒度

针对微服务拆分过细导致的问题，我建议基于团队规模进行拆分，类似贝索斯在定义团队规模时提出的“两个披萨”理论（每个团队的人数不能多到两张披萨都不够吃的地步），分享一个我认为微服务拆分粒度的“三个火枪手”原则，即一个微服务三个人负责开发。

为什么是 3 个人，不是 4 个，也不是 2 个呢？

首先，从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；

其次，从团队管理来说，3 个人可以形成一个稳定的备份，即使 1 个人休假或者调配到其他系统，剩余 2 个人还可以支撑；如果是 2 个人，抽调 1 个后剩余的 1 个人压力很大；如果是 1 个人，这就是单点了，团队没有备份，某些情况下是很危险的；

最后，从技术提升的角度来讲，3 个人的技术小组既能够形成有效的讨论，又能够快速达成一致意见；如果是 2 个人，可能会出现互相坚持自己的意见，或者 2 个人经验都不足导致设计缺陷；如果是 1 个人，由于没有人跟他进行技术讨论，很可能陷入思维盲区导致重大问题；如果是 4 个人或者更多，可能有的参与的人员并没有认真参与，只是完成任务而已。

“三个火枪手”的原则主要应用于微服务设计和开发阶段，如果微服务经过一段时间发展后已经比较稳定，处于维护期了，无须太多的开发，那么平均 1 个人维护 1 个微服务甚至几个微服务都可以。当然考虑到人员备份问题，每个微服务最好都安排 2 个人维护，每个人都可以维护多个微服务。

拆分方法

基于业务逻辑拆分

将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。
从业务的角度来拆分的话，规模粗和规模细都没有问题，因为拆分基础都是业务逻辑，要判断拆分粒度，不能从业务逻辑角度，而要根据前面介绍的三个火枪手的原则，计算一下大概的服务数量范围，然后再确定合适的职责范围，否则就可能出现划分过粗或者过细的情况。

基于可扩展拆分

将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。

稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中；

这样拆分主要是为了提升项目快速迭代的效率，避免在开发的时候，不小心影响了已有的成熟功能导致线上问题。

基于可靠性拆分

将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。这样拆分带来下面几个好处：

避免非核心服务故障影响核心服务；
核心服务高可用方案可以更简单(业务逻辑单一)；
能够降低高可用成本，将核心服务拆分出来后，核心服务占用的机器、带宽等资源比不拆分要少很多；

基于性能拆分

基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。

以上几种拆分方式不是多选一，而是可以根据实际情况自由排列组合

基础设施

大部分人主要关注的是微服务的small和lightweight特性，但实际上真正决定微服务成败的，是那个被大部分人都忽略的automated。如果automated相关的基础设施不健全，那微服务就是焦油坑，让研发、测试、运维陷入各种微服务陷阱中。

微服务并不是字面表现的那样又简单又轻量级，相较于SOA微服务并没有减少复杂度，而只是将复杂度从 ESB 转移到了基础设施。

虽然建设完善的微服务基础设施是一项庞大的工程，但是：

已经有开源的微服务基础设施全家桶了，例如 Spring Cloud 项目，涵盖了服务发现、服务路由、网关、配置中心等功能；
如果微服务的数量并不是很多的话，并不是每个基础设施都是必须的；

建议按照下面优先级来搭建基础设施：

服务发现、服务路由、服务容错：这是最基本的微服务基础设施；
接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率；
自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率；
服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率；

以上 3 和 4 两类基础设施，重要性会随着微服务节点数量增加而越来越重要，但在微服务节点数量较少的时候，可以通过人工的方式支撑。

基础设施篇

自动化测试

自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都自动化。如果因为团队规模和人力的原因无法全面覆盖，至少要做到接口测试自动化。

自动化部署

自动化部署系统包括版本管理、资源管理（例如，机器管理、虚拟机管理）、部署操作、回退操作等功能。

配置中心

配置中心包括配置版本管理、增删改查配置、节点管理、配置同步、配置推送等功能。

接口框架

微服务提倡轻量级的通信方式，一般采用 HTTP/REST 或者 RPC 方式统一接口协议。但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式。
接口框架不是一个可运行的系统，一般以库或者包的形式提供给所有微服务调用，例如protobuf

API网关

系统拆分为微服务后，内部的微服务之间是互联互通的，相互之间的访问都是点对点的。而对于外部系统的访问操作需要一个统一的API网关，主要包括接入鉴权（是否允许接入）、权限控制（可以访问哪些功能）、传输加密、请求路由、流量控制等功能。

服务发现

服务发现主要有两种实现方式：

自理式
自理式结构就是指每个微服务自己完成服务发现，如下图 SERVICE INSTANCE A 访问 SERVICE REGISTRY 获取服务注册信息，然后直接访问 SERVICE INSTANCE B

自理式服务发现实现比较简单，因为这部分的功能一般通过统一的程序库或者程序包提供给各个微服务调用，而不会每个微服务都自己来重复实现一遍；并且由于每个微服务都承担了服务发现的功能，访问压力分散到了各个微服务节点，性能和可用性上不存在明显的压力和风险。
代理式
代理式结构就是指微服务之间有一个负载均衡系统，由负载均衡系统来完成微服务之间的服务发现

代理式的方式看起来更加清晰，微服务本身的实现也简单了很多，但实际上这个方案风险较大：第一个风险是可用性风险，一旦 LOAD BALANCER 系统故障，就会影响所有微服务之间的调用；第二个风险是性能风险，所有的微服务之间的调用流量都要经过 LOAD BALANCER 系统，性能压力会随着微服务数量和流量增加而不断增加，最后成为性能瓶颈。因此 LOAD BALANCER 系统需要设计成集群的模式，但 LOAD BALANCER 集群的实现本身又增加了复杂性。

不管是自理式还是代理式，服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务或者 LOAD BALANCER 系统到服务注册表查询可用服务。

服务路由

服务路由和服务发现紧密相关，服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的。
对于自理式服务发现，服务路由是微服务内部实现的；对于代理式服务发现，服务路由是由 LOAD BALANCER 系统实现的。无论放在哪里实现，服务路由核心的功能就是路由算法，常见的路由算法有：随机路由、轮询路由、最小压力路由、最小连接数路由等。

服务容错

常见的服务容错包括请求重试、流控和服务隔离。通常情况下，服务容错会集成在服务发现和服务路由系统中。

服务监控

服务监控的主要作用有：

实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间；
服务监控可以在实时分析的基础上进行预警，在问题萌芽的阶段发觉并预警，降低了问题影响的范围和时间。

通常情况下，服务监控需要搜集并分析大量的数据，因此建议做成独立的系统，而不要集成到服务发现、API 网关等系统中。

服务跟踪

服务监控可以做到微服务节点级的监控和信息收集，但如果我们需要跟踪某一个请求在微服务中的完整路径，服务监控是难以实现的。因为如果每个服务的完整请求链信息都实时发送给服务监控系统，数据量会大到无法处理。

服务监控和服务跟踪的区别可以简单概括为宏观和微观的区别。例如，A 服务通过 HTTP 协议请求 B 服务 10 次，B 通过 HTTP 返回 JSON 对象，服务监控会记录请求次数、响应时间平均值、响应时间最高值、错误码分布这些信息；而服务跟踪会记录其中某次请求的发起时间、响应时间、响应错误码、请求参数、返回的 JSON 对象等信息。