阿里云云原生微服务 ACP （一）：什么是云原生微服务

基本概念

Sam Newman于2016年发布的《Building Microservice（微服务设计）》一书中说：随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也应运而生。根据Wiki上的说法，2014年Martin Fowler与James Lewis共同提出了微服务的概念，他们在博客Microservices中提到：The term “Microservice Architecture” has sprung up over the last few years to describe…。我们暂且将微服务架构的诞生时间设定为2014年，从云的发展时间线上看：

2014年，以Cloud Foundry为代表的开源PaaS以及其他基础设施厂商（例如CoreOS、RedHat等）正承受Docker平台化带来的巨大压力，同年，Google宣布Kubernetes项目，至此，容器作为应用打包的基本形式再无争论，各家在容器编排系统这个制高点上展开竞争，最后K8s胜出，作为该领域的事实标准。再回到2016年，我们看到类似不可变基础设施、声明式API这样的创新使得在云上管理微服务更加容易，Ops问题少，才能显出Dev的价值。此时，云与微服务有了一个很强的连接点。

在另一个方面，云作为新的基础设施，有意愿也有能力发挥更大的价值，自然也就有了云原生的概念，即在云上构建应用，它的发展脉络是这样的：

• 2011年，Heroku提出了十二因子应用定义（详细内容参考The Twelve-Factor App），通常被认为是最早的云原生应用的技术特征，它描述了云原生应用的技术特征，十二因子覆盖应用的设计、构建、发布、运行各个环节，**面向的读者是：任何SaaS应用的开发人员；部署和管理此类应用的运维工程师。但是其愿景中的SaaS关于云的部分仅仅是：适合部署在现在的云计算平台，从而在服务器和系统管理方面节省资源。**受见识限制，我觉得，如果说十二因子描述了云原生，可能是云的一厢情愿，也有可能是其他原因，但是能够看到云的野心
• 2015年，Pivotal提出了云原生的概念，即云原生是一种可以充分利用云计算优势的构建和运行应用的方式。结合2015年这个时间点来看，这是一个能够想象云的未来景象的时刻，但云的优势是什么，又该如何利用呢，有点隐而不发的意味，直到2017年，Pivotal更新了定义，指出了云原生应用的要素是DevOps、持续交付、微服务和容器
• 2015年，CNCF成立，更加具体的定义了云原生：容器化封装+自动化管理+面向微服务，在云原生领域，CNCF拥有更大的话语权
• 2018年，CNCF更新了云原生的定义：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API；这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更；云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

现在我们可以基本理解为什么是“云原生微服务”了，云能够更好地管理微服务架构应用、开源在云原生领域很重要、类似DevOps这样的工程实践必不可少，以及云进一步渗透后，告诉开发者：你只需要关注业务逻辑。

关于云原生是什么，对CNCF的定义做个总结：云原生是种架构模式及软件开发的新的思想理念。也有人说它是一种文化，可能难以养成且生效缓慢，不过没有人说它能够让你的业务水涨船高。**一个现实是，云原生微服务是技术领域的产物，它不是促进业技融合的方法论，只是业务敏捷的基础。**站在云厂商的角度必须更加具体的描述云原生微服务：

可以看到，阿里云使用以下体系帮助构建微服务架构应用，也即云原生的三要素，容器、微服务和DevOps：

• 基于IaaS构建容器运行环境，使用K8s完成容器编排与调度
• 使用云上的SaaS、PaaS能力构建松耦合的微服务架构应用，包含应用依赖、微服务管理两方面的能力，例如服务治理、可观测性、网关、网格、Serverless、安全、数据库、中间件等
• 支持DevOps工具链，这里可能不仅限于云效（一站式研发系统平台）提供的能力，还包括混沌工程之类的反脆弱实践

还有一个重要的话题，微服务好在哪里，这似乎是关于云原生价值的重要讨论，简单列举一下《微服务设计》中的内容：

1. 技术异构性，在不同的微服务中使用最适合该服务的技术，或者可以帮我们更快地使用新技术，虽然使用多种技术会付出代价，但是微服务是寻找平衡的过程
2. 弹性，微服务边界就是弹性边界，如果系统中的一个组件不可用了，但并没有导致级联故障，那系统的其他部分还可以继续运行，需要谨慎对待弹性问题，考虑出现问题时如何对用户展示
3. 扩展，可以只对需要扩展的服务进行扩展
4. 简化部署，微服务中每个服务是独立的，因此可以实现对特定部分代码的频繁部署
5. 与组织结构相匹配，微服务架构可以很好地将架构与组织结构相匹配，避免出现过大地代码库，从而获得理想的团队大小和生产力，避免异地团队出现
6. 可组合性，在微服务架构中，系统会开放很多接口供外部使用，易于重用已有的功能
7. 对可替代性的优化，在微服务架构中重新实现某一个服务或者直接删除该服务都是相对可操作的

可以看出相比单体应用，微服务能够支持业务的快速迭代，而云上的支撑能力极大地降低了使用微服务的负担。在数字化时代的背景下，云原生微服务架构可能是适应快速变化的首选，这似乎也是开源对于云原生如此重要的原因，谁能允许未来在某个基础设施厂商手中呢

微服务体系

阿里云对云生的断言是成为云计算的新界面、重塑软件生命周期、加速信息产业转型升级，简单总结一下就是云要更加易用、服务化更多的IT能力、让开发者基于云构建业务，是把云原生当成未来看待的，并且在2020年将云原生升级为阿里技术新战略，其产品矩阵如下：
整个云原生产品体系构建在公共云、专有云和混合云的IaaS层之上，由：容器编排、Serverless、可观测性以及高可用、安全能能力建立微服务运行环境，再由PaaS和SaaS：服务数据&智能、分布式应用架构、DevOps直接服务于应用的设计和构建过程，形成应用开发环境，涉及产品简介如下：

• 运行环境
  • 容器编排
    • 容器服务ACK，ACK是一个产品系列，简单说是一个通过一致性认证的云上的托管或者自己管理的K8s集群，能够集成云上的其他服务，例如ACR、ECI等，针对边缘计算、混合云多集群、异构计算、AI有对应的解决方案
    • 容器镜像服务ACR，是面向容器镜像、Helm Chart等符合OCI标准的云原生制品安全托管及高效分发平台
    • 托管服务网格ASM，统一管理微服务流量，兼容Istio的托管式平台（控制平面托管），支持K8s集群、ECS集群及自建集群通过代理集成，似乎是这类方案通用的集成方式
  • Serverless
    • Serverless K8s ASK，是ACK系列的一员，无需管理集群即可提交K8s应用，Pod基于ECI运行在隔离环境中，为与K8s兼容，一个ECI实例可视为一个Pod，同属一个虚拟交换机的ECI可视为在同一个Node
    • 弹性容器实例ECI，提供镜像即可运行容器，ECI底层似乎是一种轻量级虚拟机，用到了Hypervisor，能够提供虚拟机级别的资源隔离（这应该是必须的，毕竟需要托管不同用户的容器），在控制面上提供OpenAPI和Virtual Kubelet，可以作为K8s的弹性资源池使用，服从K8s管理
    • Serverless应用引擎SAE，零代码改造、自适应弹性的应用全托管平台，主打场景应该是JAVA微服务的弹性托管和任务托管，实现Serverless应用和微服务的整合
    • 函数计算FC，事件驱动的全托管Serverless计算服务，例如一次HTTP请求、Jenkins流水线中的任务
  • 可观测性以及高可用
    • 应用实时监控服务ARMS，包括应用监控/应用监控eBPF版、移动应用监控、前端监控、Prometheus、Grafana、K8s监控、应用安全、云拨测、链路追踪、告警管理
    • 可观测链路OpenTelemetry版，ARMS产品系列之一，针对多语言提供端到端链路追踪、应用监控与告警、链路拓扑、日志关联分析，基于OpenTelemetry标准兼容Jaeger、Zipkin、SkyWalking等开源项目数据上报
    • 日志服务SLS，为Log、Metric、Trace数据提供平台化服务
    • 应用高可用服务AHAS，通过多活容灾提高应用的高可用能力，提供流量入口、应用层、数据故障切换以及故障演练等能力建设同城和跨地域多活建设
  • 安全
    • 云安全中心，实时识别、分析、预警安全威胁的主机和容器安全管理系统，提供病毒检测查杀、漏洞检测修复、基线检查、资产指纹、攻击分析、镜像安全扫描、容器K8s威胁检测、容器网络拓扑等能力
• 开发环境
  • 数据&智能
    • 云原生数据库PolarDB/RDS，包含关系型数据库、NoSQL数据库、数据库管理工具、数仓
    • 通用计算平台MaxCompute/EMR，大数据与数据湖
    • 人工智能平台PAI，机器学习和深度学习工程平台
    • 实时计算Flink版，Flink流式计算
  • 分布式应用架构
    • API网关，API托管服务，覆盖API全生命周期
    • 消息队列MQ/Kafka，包含RocketMQ、RabbitMQ、MQTT、MNS、EventBridge、Kafka
    • 企业级分布式应用服务EDAS，一站式集成微服务、可观测、任务调度等技术的应用PaaS平台，如果以稳敏双态度来描述，EDAS可以支撑复杂的企业级技术架构上云
    • 微服务引擎MSE，面向业界主流微服务框架的套件，整体上对JAVA友好的，在接入ASM后，可以兼容Istio，实现语言无关的支持能力，是开源框架Spring Cloud Alibaba的企业版
  • DevOps
    • Cloud Shell/Toolkit，云命令行与IDE插件
    • 云效，研发协同工具
    • 移动研发EMAS，移动端研发平台
    • Spring Cloud Alibaba，JAVA微服务开源框架，阿里提供企业版MSE

还应该加入这个图谱的包括：

• 性能测试PTS，支持按需发起压测任务，提供场景编排、API调试、流量定制、流量录制等功能，可快速创建业务压测脚本，精准模拟不同量级用户访问业务系统，兼容JMeter

以上产品中，包含在ACP教材中的有：EDAS、SAE、FC、RocketMQ、Kafka、ARMS、PTS、AHAS，是云原生微服务的关键能力，覆盖应用程序全生命周期，产品矩阵应该是比较复杂的，但部分产品更加类似于解决方案，是由原子产品集成，例如EDAS。这里需要再次说明，以上产品只是技术层面的产物，业务价值能否被放大至少还依赖微服务和组织架构的设计，这是云原生的另一个复杂性，可能需要企业架构、领域驱动设计等理论支持，以演进的方式看待微服务架构。

开源生态

之前粗略猜测了云原生领域核心项目开源的原因，即基础设施不能被垄断，围绕云原生的厂商基本都在积极投入开源项目，在创造更好的解决方案的同时，可能也是在为云原生技术生态注入活力。阿里的所有开源项目可参考阿里巴巴开源，在微服务领域主要是Spring Cloud生态的全家桶Spring Cloud Alibaba，摘抄简介如下：

• Sentinel，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性
• Nacos，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台
• RocketMQ，一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务
• Seata，阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案
• Dubbo，高性能的Java RPC框架

这里是微服务领域主流框架的一个简单对，虽然你可以直接使用阿里的套件，但开源项目会在管理功能上有一些阉割，比如非常差劲的控制台之类的：

下回分解

详细了解EDAS

推荐阅读

• 《微服务设计》
• 《如何落地业务建模》