全文字数：4361字，精读时间：9分钟

本文援引于报告《2021年云原生行业研究报告(一)：微服务》，首发于头豹科技创新网（www.leadleo.com）。

头豹科技创新网内容覆盖全行业、深入垂直领域，行业报告每日更新；政策图录、数据工具助您轻松了解市场动态；智能关键词轻松搜索，直奔行业热点内容。

诚挚欢迎各界精英交流合作，头豹承接行业研究、市场调研、产业规划、企业研究、商业计划、战略规划等业务，您可发送邮件或来电咨询。

客服邮箱：CS@leadleo.com 咨询热线：400-072-5588

云原生通过微服务、容器化、持续交付、DevOps等技术，赋能企业在云基础设施上，实现速度、可扩展性和利润的提升

区别于从本地环境移植到云上的大部分程序，云原生强调最初的开发就是为了最终部署到云环境上。在公有云、私有云和混合云等新型动态环境中，赋能组织或企业去构建和部署可弹性扩展的应用。

云原生由三点目的：

速度：将想法快速实现推向市场在竞争中具有极大的战略意义。云原生本质上是关于如何解决技术风险的策略，配合企业内部文化向渐进式改进的开发模式转变，依靠采取小型、可逆和低风险的步骤来实现迅速前进，极大缩短开发周期。

可扩展性：云原生应用将其状态存储在数据库或其他外部实体中，不依赖于底层基础设施，只需向集群添加节点就可以扩展应用程序。

利润：企业支出从前期的 CAPEX（购买新机器以预期成功）变成了 OPEX（按需支付额外的服务器）。实现只在新客户上线时购买所需的额外资源的战略目标，满足灵敏响应和可控管理成本的需求。

应用架构为了满足扩展弹性与适配大型项目开发运维的需求，逐渐向松散耦合，细粒度的微服务应用架构发展

根据业务和功能要求，应用架构描述了业务中使用的应用程序的行为，着重于它们之间以及与用户的交互方式，确保组织用来创建复合体系结构的应用程序套件是可伸缩，可靠，可用和可管理的。伴随着企业业务发展所需的软件代码库的扩张，由于集中式研发、测试、发布、沟通模式，应用迭代效率显著下降。

第四代微服务架构- 多运行时微服务架构 Multi-Runtime Microservices

自AWS Lambda出现后，应用开始尝试利用Serverless无服务器来补充微服务架构，促进了没有虚拟机或者容器的微服务。当服务应用的一个组件请求更多的计算资源，低资源的事件就可以触发Serverless的函数计算，从而提供另外的组件实例，而无需创建一个独立的组件来处理这个事件。于是在此架构中，微服务进一步由一个应用简化为Micrologic微逻辑，从而对SideCar提出了更高的诉求，将更多可复用的分布式能力从应用中剥离下沉到SideCar中，例如状态管理、资源绑定、链路追踪、事务管理、安全等等。

随着Serverless资源的实现和云原生思想的影响，未来的架构趋势是将Mesh深化，应用需要的分布式能力需要继续下沉，越来越多的能力会以 Sidecar 的形式出现，但运维压力也催生了新的形态Mecha来解决SideCar过多的问题。此时，应用核心的业务逻辑（称为微逻辑）和强大的开箱即用的分布式原生功能Mecha组件共同组成多运行时微服务。

Mecha的目的是成为面向应用的分布式能力抽象层。目前还处在一个起步探索的过程，在Service Mesh 现有的固定模式之上，尝试Node模式取代SideCar，尝试用Runtime解耦底层实现取代通讯协议转发，尝试保留轻量SDK提供统一的API接口，开始提倡localhost编程的开发侧理念。

微服务具备敏捷开发、弹性伸缩和高可用的优势，但由于其复杂且高昂的的前期实现搭建，微服务并非适合所有场景

适用场景一：企业规模较大，系统复杂

微服务需要对前期基础设施投资，架构本身的额复杂性高，涉及的技术栈多。如果小企业采用微服务，首先对问题领域不了解导致很难划分服务的边界，开发的成本和风险较高，更推荐单体架构。当公司发展至业务已经到达了一定的复杂性，微服务可以提升研发和交付的效率，满足增长需求。

适用场景二：软件即服务（Software as a Service, SaaS）

SaaS具有高度场景化、关注用户体验和短流程的特点。用微服务架构提供SaaS服务，可以同时高度满足定制开发、可配置、多租户、高性能、伸缩性的最高级别成熟度模型。

虽然微服务架构下的SaaS需要面对较高的运维、前期领域驱动设计和DEVOPS要求所带来的成本，但微服务能够提供容器化独立部署，可以直接被外部或其他服务调用，将每一个碎片化的SaaS服务场景由微服务平台统一管理和编排。

适用场景三：混合云/多云架构应用管理

混合云和微服务架构各自的性质契合，凸显了微服务在混合IT架构管理方面的适用性：混合云的各项服务相互响应的能力必须满足松耦合，而其也同样遵循API控制、负载均衡等管理基础技术。

适用场景四：IT架构云端迁移

迁移效率和可用性是大型企业IT架构云端迁移关注的重点。由于涉及基础设施架构的跨度较大，IT系统在从金属机向虚拟机迁移过程中，如何快速高效得实现应用与基础设施的解耦是关键的问题。

微服务架构相较于单体架构能够极大地提升云端迁移的效率，原因如下：

单体应用的复杂性远高于在经过拆分后的若干个细粒度的微服务；

单体架构无法一次性完成向云迁移，通过对原有应用分步解耦并独立上云，存在一个传统架构与云架构并存的过渡时期，经由微服务平台进行云端整合。

微服务架构与云计算相辅相成

一方面，企业级SaaS服务和云端迁移的高速发展正是微服务架构普及的重要驱动因素。另一方面，微服务架构作为高效成熟的云计算相关技术，推动了企业上云的进程。

微服务通过领域驱动设计完成业务拆分，协同IT团队的架构调整与平衡系统架构的设计，逐步完善微服务架构改造

在传统单体架构下，企业中不同的IT团队以不同的职能划分，通过不同团队之间的协作共同开发项目。而微服务架构改造后，原有的IT系统被拆分成大量的微服务组件，需要围绕每一个独立的微服务能力组建一个从开发到运维的完整团队，从而满足“康威定律”保持技术架构与企业架构一致

领域驱动设计

对原有系统的有效拆分是微服务实现的关键，在微服务设计过程中，要先对企业原有的业务和架构进行梳理和规划，据此进行领域驱动设计（Domain Driven Design, DDD）。DDD追求精确反映领域中某一知识元素的载体，通过与领域专家进行频繁的沟通将专业知识转化为领域模型。

落地方式

不同行业及不同企业中的业务拆分方案不同，微服务设计要求不同的对包括团队架构和技术架构的实现过程，体现了微服务落地存在极高的个性化特色，兼具行业壁垒和技术壁垒。落地方案有两种：

借力外部架构咨询公司提供架构DEMO和培训服务助推内部技术团队。

招聘相关经验丰富的人员进来，自行研究和搭建架构并做内部培训。

微服务市场发展驱动因素分析

1.大量成熟的微服务供应商可供企业用户选择

互联网厂商和传统IT厂商已完成前期的技术积累和应用试错经验，在企业IT开始考虑进行微服务架构改造时，微服务供应商已可提供大量成熟的微服务应用案例并为企业用户提供相关的咨询与实施服务。

2.微服务领域的开源数字化

Quarkus 作为云原生微服务框架，全球 GitHub 开源项目活跃度中排名 40；

Spring 作为 Java 微服务框架事实标准，在微服务框架中活跃度位列二三；

Apache Dubbo 作为中国本土开源的项目，微服务框架活跃度排名第五。

微服务的活跃开放，促进了标准与接口的统一，推动了微服务行业的发展。

3.微服务架构转型需求激增

微服务技术在互联网公司快速发展的过程中已经发挥了重要的作用。 Netflix在2008年因为全站瘫痪被迫停业3天后，开始进行服务化架构改造，经过十余年的开发实现了从单体架构到微服务的变迁，支撑了业务的千倍增长，是微服务架构的先驱，带动了国内外互联网领域的微服务化。

在传统行业中，包括工业制造、交通物流、金融、零售、地产、医疗等领域正面临大量新兴业务场景的出现，服务变得复杂，单体架构已不能满足业务发展对迭代速度、可用性、流量峰值和系统互通的要求，微服务化需求明显。

4.云计算技术红利吸引

底层硬件的迭代和顶层业务发展诉求不断升级共同驱动了计算机软件技术架构的进化。云计算进入工业化应用后，用虚拟机替代了物理机，如今的容器技术与Serverless的融合跨代际得实现了计算密度的升级，提供了最佳的性能功耗比和性能价格比，大幅降低了用户使用门槛的同时吸引着各行各业的IT团队对其上层应用微服务化以享受云计算带来的技术红利，其灵活性与成本优势加速了数据服务的云原生化。

5.微服务架构贴合未来软件技术发展趋势

微服务架构具有两大特点：

1. 独立通讯 Transport Independence：意味着消息如何传输是无关紧要的，消息传递模型的级别 是同步或异步无关紧要。重要的是，消息成为了唯一的界面，通过组合服务，大大减少了组件的集成面。

2. 无身份 Zero Identity : 微服务和组件不得互相了解。消息简单地发送和接收，无需考虑目的地。这种方法使动态的实时修改系统成为了可能。在一些实例中，仍能看到依赖于嵌入在服务中的身份，而这是一个最大的错误，导致了大多数微服务的崩溃。

有了这两个特点作为微服务的底层原则，或许在未来将看到“微服务”这个词会消失，意味着它们将真正融入成为软件开发的主流架构。兴许在未来还会出现Macro-service或Nano-service命名的新一代应用架构，但微服务架构带来的理念和技术积累将继续沉淀。

微服务市场吸引了互联网厂商、云服务厂商、传统IT实施服务商、应用软件开发厂商及初创企业参与布局，从提供的产品或服务的视角区分，微服务市场参与者主要分三类

在传统数据库中，大量地使用启发式算法通过传统经验去优化数据库，已然无法满足更高的执行要求，比如针对众多用户的实际场景进行定制化开发。过去采用系统预定义参数组合或可调节参数开关等方式，由DBA根据经验进行调整。

利用AI算法替代启发式算法，解决传统数据库的痛点，典型方向有：

优化器：传统代价优化基于采样统计信息进行表连接规划，存在统计信息不准、启发是连接规划等问题。

参数调优：数据库有数十至上百个可调节参数，其中很多参数时连续值调节空间，依靠人工经验无法找到最优参数组合。

自动化索引推荐和视图推荐：在数据库的众多表与列中自动构建索引和视图，来提升数据库的性能。

事务智能调度：事务的并发冲突时OLTP的难点，可以通过人工智能进行智能调度来提升数据库的并发性能。

深度见解：

应用架构的演进和生物物种的进化有着共同的内核：物竞天择，适者生存。随着信息技术的日新月异，传统架构已经不能适配不断迭代的底层硬件和不断升级的顶层业务发展诉求。

微服务架构在2016年后随着容器技术一起成为技术热点，以Spring Cloud为代表的侵入式开发框架占据着微服务市场的主流地位，Spring微服务框架+Docker容器+K8s集群管理被誉为在春天的货船上的盛世。

逐渐，非侵入式的服务网格Service Mesh走向成熟，到Linkerd、Envoy、Istio、Conduit等框架选型的出现，微服务市场从框架、组件、到容器等产品系列与生态的不断发展与完善，大大降低了微服务从技术理念到产品落地的门槛，使微服务企业用户最为重视的架构方式之一。