撰稿：千山微服务概念自诞生以来，就伴随着诸多热议。人们要么喜欢它，要么讨厌它，似乎没有太多的中间立场。在微服务如火如荼的这几年，很多公司都尝试过微服务转型。当时，微服务架构提供了一种重构现有系统的新方法，并以提供模块化、可扩展性和可用性的能力成为软件开发行业的新宠。但任何架构都不会是适应所有问题的万能钥匙，微服务也不例外。近年来，一些企业放弃微服务实践，选择回归单体架构的消息也不时出现在公众视野中。不久前，GitHub前CTOJasonWarner在Twitter上直接表示，“我确信过去十年中最大的架构错误之一就是对微服务的充分利用。”激起无数涟漪。我们知道微服务并不是对每家公司都适用，但选择与否，其背后的根本原因还是值得深思的。1.为什么选择微服务2003年前后，DDD、EIP等软件设计开始流行，一些团队尝试将应用开发成模块化服务，但传统基础设施对模块化部署并不友好。随着云计算的发展和云托管的普及，像Heroku这样的平台方便了模块化部署。这也为微服务创建细粒度和可重用的功能提供了可能。传统单体架构的优缺点是显而易见的。优点是前期开发简单，容易对程序进行大的改动。但随着业务的发展，开发效率低、扩展性差、缺乏故障隔离等问题会逐渐暴露出来。单体地狱”。微服务的出现在架构思维上提供了一种新的解决方案：将服务按照业务领域划分成多个块，相应地，代码可以分解成更小的部分，可以独立开发、测试、部署和部署。更新。它提供复杂应用的持续交付，使应用更容易理解、开发、测试，更能抵抗架构侵蚀。尤其是在开发大型应用时，这种优势会更加突出。在微服务相关的推荐文章中，对微服务的赞誉大致可以归结为：保证服务的可扩展性：由于每个服务都是一个独立的组件，可以使用更多的容器来部署扩展，从而实现更高效的容量规划降低耦合简化团队协作：单一目的设计意味着它们可以由较小的团队构建和维护。每个团队都可以跨职能，同时也专注于解决方案中的微服务子集。改进的故障隔离：在微服务架构中，如果单个模块受到影响，它可以很容易地拆除或解决，而不会影响应用程序的其他部分。易于修改技术堆栈：借助微服务，软件开发公司可以在特定组件上尝试新堆栈或最新技术。由于没有依赖性问题，软件开发人员可以避免使用特定的技术栈。大数据世界中的各种技术（包括开源社区）在微服务架构中运行良好。提高开发效率，提高生产力：不同的团队同时在不同的组件上工作，无需等待一个团队完成任务。这提高了工作效率并加快了产品发布。可以肯定的是，采用微服务架构构建的系统有很多好处，比如独立部署、强大的子系统边界、有保障的技术多样性等等，这也是微服务架构一度受到很多公司青睐的原因。然而，任何事情都有两个方面，微服务架构也有其缺点。2、我们需要的不是微服务，模块微服务在解决了单体架构的诸多顽症后，也带来了其他的挑战。我们可以列举几个：第一，判断是否适合做微服务，还要看具体的业务场景。如果只是为了分裂，那肯定是没有意义的。而且微服务的设计也比较复杂。比如应该拆分成多少个微服务？新的需求来了，是新建微服务还是在老系统上改造？都需要综合考虑。可以说，设计糟糕的微服务架构比设计糟糕的单体架构要麻烦得多。二是提高了发展的技术门槛。鉴于微服务是一个分布式系统，它也以与开发分布式应用程序相关的复杂性为代价，例如独立的数据模型、微服务之间的弹性通信、最终一致性和操作复杂性。开发和运行大规模分布式服务并不容易。企业发展壮大，有了分布式系统，几十个微服务就已经很难推理了，更何况是上百个微服务本身就有风险。此外，它增加了操作和维护的复杂性。在某种程度上，微服务提供的敏捷性和开发效率是以增加操作复杂性为代价的。服务拆分成多个微服务，每个微服务会部署很多套。人肉运维显然不适合。此外，所有服务可能都需要集群以实现故障转移和弹性。您的系统可能有几十个单独的组件，并且随着新功能的添加，它会变得更加复杂。当稍微权衡一下微服务的优劣时，我们需要重新审视的是我们在谈论微服务时看重的是什么；我们在选择微服务的时候关注的核心是什么。事实上，在上面列出的微服务的优点中，稍微注意一下就可以发现，大多数争论都反映了一个共同的主题：创建和维护小型、独立的代码和数据“块”的思想，它们彼此分离其他并使用通用输入和输出以实现更好的系统集成。都指向微服务必不可少的关键词——模块。太阳底下并无新鲜事。自1970年代以来，“模块”的概念一直是大多数编程语言的核心。CLR（c#、f#、VisualBasic...）上的“程序集”、JVM（Java、Kotlin、Clojure、Scala、Groovy...）上的“jar”或“包”，或动态链接库对于操作系统（在Windows上的dll、sos或*nixes上的dll，当然macOS在/Library目录中隐藏了“框架”）。无论形式如何，在概念层面上都是模块。它们都有不同的内部格式，但都有相同的基本目的：可以独立构建、管理和部署的可重用代码单元。出自DavidParnas于1971年撰写的论文《关于将系统分解为模块的标准》，其中定义明确的“独立、不同的程序模块”抓住了微服务的大部分内在优势。可以说，追求系统“模块化”已有半个世纪的悠久历史。那么为什么微服务会引起如此多的关注呢？因为微服务解决的与其说是技术问题，不如说是人的问题。关键词不是服务或分布式系统，而是组织清晰度。3.是建筑问题，也是“人”的问题。如果你做过微服务相关的工作，你可能听说过“康威定律”。这是MelvinConway在1967年提出的一个观点，大致的意思是，一个组织的系统通常被设计成组织沟通结构的复制品。设计系统的组织……被迫产生设计，这些设计是这些组织的通信结构的副本。—>M.Conway简而言之，你想要什么样的系统设计，你想要建立什么样的团队。解决方案围绕团队结构（和团队沟通开销）进行“优化”，不一定要解决特定的技术或性能问题。最好按业务划分团队。这样，团队就可以自然而然地自治和自洽。清晰的业务边界将降低跨境沟通成本。每个小团队负责自己模块的整个生命周期，权责分明，没有无效的扯皮和搪塞。微服务可以说在一定程度上对组织结构进行了倒逼。通常IT公司的职位会分为产品、开发、测试、运维等，有的公司甚至会分成不同的部门。从开发到上线，一个需求会在不同部门之间不断流转，微服务往往被用来加速业务响应，减少开发团队面临的依赖。在微服务架构下，其组织架构也必须进行相应的调整。团队要么由各种技能各异的人组成，要么每个团队成员技能齐全（所谓“全栈开发”）。”）。同时，这个团队还负责一个或多个微服务的迭代和运维。当然，康威定律的好处在很大程度上取决于边界在哪里划定以及这些边界如何随时间变化。所以在尝试微服务之前，首先要考虑的是，是否真的有必要减少开发团队所面临的依赖，团队是否对自己要构建的东西有清晰的认识，是否愿意承担后果这可能会导致风险。软件服务公司InVision的技术架构经历了从微服务融合回单体架构的过程，其技术人员BenNadel曾这样描述这样选择的原因：“多年来，InVision必须从组织和基础设施的角度发展。这意味着在幕后，有一个较旧的“遗留”平台和一个不断发展的“现代”平台。随着越来越多的团队迁移到‘现代’平台，这些团队之前负责的服务移交给了剩下的‘遗留’团队。”可悲的是，BenNadel的团队是“遗留”团队。“该团队一直在慢慢但稳步负责越来越多的服务。这意味着：更少的人，但更多的代码存储库、更多的编程语言、更多的数据库、更多的监控仪表板、更多的错误日志。”简而言之，随着时间的推移，康威定律对组织的所有好处都会成为“遗产”的责任团队。“因此，我们一直在尝试‘调整’责任范围，以将平衡带回康威定律。或者，换句话说，我们一直在尝试更改服务边界以匹配团队的边界。这意味着，将微服务重新合并为单体架构。”因为微服务不仅涉及技术架构问题，当涉及到“人”问题时，往往会造成“水能载舟，亦能覆舟”的效果。4.结语很多公司都尝试过微服务转型，有转型成功的，也有半途而废的，原因有很多，毕竟采用微服务其实是转移复杂性，而不是消除复杂性。如果你的系统不够大，团队成员不同，现有的技术架构完全可以满足业务需求，那根本没必要选择微服务，微服务的意义从来不是“微”，而是“规模合适”的服务负责功能的“适量”。这里的契合不是一个静态的标准。它通常取决于多个因素，例如团队的技能组合、组织状态和回报投资上。更重要的是，这不仅仅是技术领域的选择，更是“人”与“组织”架构的选择。参考链接：https://img.ydisp.cn/news/20230109/upovtdkvjqn
