架构设计内容分享(九十四)：微服务的陷阱

之乎者也·

已于 2024-02-02 23:28:03 修改

阅读量1k

点赞数 17

分类专栏：架构设计内容分享微服务架构与实践文章标签：微服务架构云原生

于 2024-01-14 16:02:20 首次发布

本文链接：https://blog.csdn.net/qq_45038038/article/details/135573796

版权

微服务架构（Microservice Architect）是一种架构模式，微服务架构是个很有趣的思维方式，其主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持，每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通，每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

参考维基百科英文版，我们简单梳理一下微服务的历史：

2005年:Dr. PeterRodgers在Web ServicesEdge大会上提出了“Micro-Web-Services”的概念。

2011年:一个软件架构工作组使用了“microservice”一词来描述一种架构模式。

2012年:同样是这个架构工作组，正式确定用“microservice”来代表这种架构。

2012年:ThoughtWorks的James Lewis针对微服务概念在QCon San Francisco 2012发表了演讲。

2014年:James Lewis和Martin Flower合写了关于微服务的一篇学术性的文章，详细阐述了微服务。

由于微服务的理念中也包含了“服务”的概念，而 SOA 中也有“服务”的概念，在“架构思维之集成”中我也讲了单体服务、SOA服务、微服务的区别，喜欢看的小伙伴可以查看。

01概述

过去的10-20年企业面临着一系列具有挑战性的情况，包括过多的异构和分散的应用程序平台（如 ERP、互联网门户）以及大量孤立的单体定制应用程序，缺乏统一的企业视图。业务流程分散在多个产品上，数据重复且不一致。当与刚性架构相结合时，交互变得效率低下，处理速度缓慢。当复杂的信息交互分布在不同的 IT 系统中时，这些问题就会加剧。最重要的是，提高竞争力和快速变化需要业务敏捷性，同时保持较低的拥有成本。借助面向服务的架构 (SOA) 计划，企业可以简化和简化复杂的交互，使他们能够专注于盈利增长。SOA技术架构如下：

SOA将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业 IT 资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。SOA帮助工程师们站在一个新的高度理解企业级架构中各种组件的开发和部署形式，它可以帮助企业系统架构师以更迅速、可靠和可重用的形式规划整个业务系统。相比于传统的垂直架构，SOA能够更加从容的应对复杂企业系统集成和需求的快速变化。

随着互联网的发展，尤其是移动互联时代的到来，整个世界的经济形态发生了巨大的变化改变。企业 IT 的重点从传统的 System of Record(交易系统，如 ERP、SCM 等)演化到 System of Engagement(互动系统，如全渠道营销)。这些系统需要能够应对互联网规模的快速增长，并且能够快速迭代，低成本试错。企业 IT 已经成为创新驱动的引擎之一，技术拓展商业边界的理想也帮助 IT 团队更有使命感，进一步加速推动了企业 IT 的进化。以 Netflix、阿里为首的一系列互联网公司主导了企业架构新的变革 - 微服务架构。Apache Dubbo, Spring Cloud 等微服务框架得到了广泛应用。微服务的核心思想便是应用功能拆分与解耦，降低业务系统实现复杂性。微服务强调将应用功能拆解为一组松耦合服务，每个服务遵守单一责任原则(Single Responsibility Principle)。微服务架构解决了传统单体式架构存在的几个固有问题：每个服务可以独立部署和交付，大大提升了业务敏捷性;每个服务可以独立横向扩展/收缩，应对互联网规模的挑战。任何事物都有其两面性，如果使用不当，反而会进入另一个极端，下面是从事架构设计多年来对于微服务架构设计和实施中总结出来的一些经验教训，分享给大家。

02认知陷阱

在进行架构重构，进行微服务化之前作为架构设计者需要认证考虑一些问题？

微服务化是为了业务还是为了自己
微服务化的目标是什么？
是所有的都微服务化还是部分微服务化？
微服务化的粒度的参考维度是什么？

2-1微服务化时间陷阱

在企业发展的初期，一般公司的网站流量都比较小，只需要一个应用，将所有的功能代码打包成一个服务，部署到服务器上就能支撑公司的业务。这样也能够减少开发、部署和维护的成本。比如，大家都很熟悉的电商系统，里面涉及的业务主要有：用户管理、商品管理、订单管理、支付管理、库存管理、物流管理等等模块，初期我们会将所有模块写到一个Web项目中，然后统一部署到一个Web服务器中。

由于微服务架构的流行，现在很多中小型企业，甚至是互联网初创公司，也跃跃欲试，打算将老的单体架构向微服务架构迁移。在这个过程中，很容易范的一个错误就是技术决策者过分关注新技术的先进性，而忽略商业目标及新技术的最佳应用场景。对于商业公司而言，技术的本质就是支撑商业的成功，它主要体现在如下3个方面。

响应公司战略，技术架构保障商业成功，例如互联网的秒杀和大促场景，使用基于Docker的秒级弹性伸缩特性，可以在业务高峰期快速地自动扩容，保障业务的正常运行，采用“传统的物理机 + 人工扩容”方式，显然无法满足业务诉求。该场景下，我们可以认为引入Docker容器技术，保障了大促业务的稳定性，为商业成功保驾护航。
控制成本，技术架构降低研发成本，例如引入新的自动化测试技术，可以实现前后台的自动化测试，将测试成本由10人月降低到1人月。通过新技术的引进，降低开发、测试、维护等成本。
企业品牌，主要针对非自营类的产品，例如电信行业、企业市场等，招标方对技术架构的先进性通常会有要求，比如支持Docker容器加10分，采用微服务架构加5分等，为了提升技术竞争力，产品往往会采用最新、最时髦的技术架构，例如“微服务 + Docker容器”技术。技术架构团队在做技术选择和决策时，需要优先考虑商业目标和业务场景，而不能只考虑技术先进性。

从单体到微服务的进化过程