江苏龙网

  1. 主页 > 生活百科 > >

微服务架构最佳实践-方法篇

架构

服务粒度当团队实施微服务架构时，可以根据团队规模来划分微服务数量 。一个团队约有 6 个人时，可以划分为 2 个微服务 。随着业务的扩展和团队规模的增加（例如，扩展到 12 个人），可以将已有的 2 个微服务进一步细分为 4 个微服务 。这种基于团队规模的微服务拆分方法，有助于管理复杂度，保持开发效率 。
为什么是 3 个人，不是 4 个或者其他数量呢？
首先，3 个人负责一个系统，每个人都能够全面理解整个系统 ， 同时又能够进行分工 。如果是 2 个人，系统的复杂度不够，开发人员可能会感到技术上的挑战不够；如果是 4 个人或者更多 ， 系统复杂度可能会导致开发人员无法全面了解系统的细节 。
其次，3 个人形成一个稳定的备份，即使其中一个人休假或者调动到其他系统 ， 剩余的 2 个人也可以支撑工作 。如果是 2 个人，剩余的 1 个人可能承担过大压力；如果是 1 个人，团队就存在单点故障 。
最后，3 个人的技术小组可以形成有效的讨论 ， 快速达成一致意见 。如果是 2 个人，可能会出现意见不一致的情况；如果是 1 个人 ， 可能会陷入思维盲区；如果是 4 个人或者更多，可能会出现参与度不足的情况 。
“三个火枪手”的原则主要适用于微服务设计和开发阶段 。当微服务经过一段时间发展后，进入维护期，无需太多开发工作时，平均每个微服务维护 1 个人或者几个微服务都是可以接受的 。然而，为了确保人员备份，最好安排每个微服务由 2 个人维护 ， 每个人可以维护多个微服务 。
拆分方法基于业务逻辑拆分：这种方式是将系统中的业务模块按照职责范围识别出来 ， 每个单独的业务模块拆分为一个独立的服务 。但在实践过程中最常见的一个问题就是团队成员对于“职责范围”的理解差异很大，经常会出现争论，难以达成一致意见 。
基于可扩展拆分：将系统中的业务模块按照稳定性排序 ， 将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务 。稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中 。
基于可靠性拆分：将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来 ， 然后重点保证核心服务的高可用 。具体拆分的时候，核心服务可以是一个也可以是多个 ， 只要最终的服务数量满足“三个火枪手”的原则就可以 。
【微服务架构最佳实践-方法篇】基于性能拆分：基于性能瓶颈将系统中的业务模块进行拆分，将性能要求高或者性能压力大的模块拆分为独立的服务 。例如 ， 电商系统中，抢购功能可能会导致性能瓶颈，可以将该功能独立为一个服务 。
基础设施大多数人关注微服务的“small”和“lightweight”特性，但实际上微服务的成败更多取决于被忽视的“automated”（自动化）方面 。为什么这样说呢？因为即使服务粒度划分不合理，当团队遇到问题时，很自然地会考虑重新拆分或合并服务；但如果与“automated”相关的基础设施不健全，微服务就会成为一个坑，使得研发、测试和运维陷入各种微服务陷阱中 。
微服务基础设施如下图所示：

微服务架构最佳实践-方法篇

文章插图
图片
 
看到上面这张图，相信很多人都会倒吸一口凉气，说好的微服务的“轻量级”呢？都这么多基础设施还好意思说自己是“轻量级” ， 感觉比 ESB 还要复杂?。?
确实如此，微服务并不是很多人认为的那样简单和轻量级 。要成功实施微服务，这些基础设施是必不可少的 ， 否则微服务可能会成为一个难以摆脱的泥潭，使业务和团队陷入困境 。因此，可以说微服务并没有减少复杂性，而是将复杂性从ESB（企业服务总线）转移到了基础设施上 。你可以看到，“服务发现”、“服务路由”等实际上都是ESB的功能，只是在微服务中被剥离出来，成为了独立的基础系统 。
虽然建设完善的微服务基础设施是一项庞大的工程，但不必因为团队规模较小或公司规模不大而放弃微服务的实施 。首先，开源社区已经提供了一些成熟的微服务基础设施解决方案，比如知名的 Spring Cloud 项目，包含了服务发现、服务路由、网关、配置中心等功能 。其次 ， 如果微服务的数量不是很多，也并非每个基础设施都是必需的 。因此，我建议按照以下优先级来搭建基础设施：


推荐阅读


上一篇：揭秘 Python 江湖中的15个冷门但超能模块

下一篇：Python图像处理库OpenCV入门教程：实践与构建