上一篇从亚马逊宕机事件出发分析了云原生背后的思想和解决的问题，在详细阐述了云原生应用和敏捷基础设施的相关技术之后，随之而来的一个问题是，云原生这么好，那我们怎么落地呢？所以，本文想聊一下基于阿里云的云原生落地姿势。打开阿里云网站发现产品眼花缭乱，选择太多导致无从选择。若是眉毛胡子一把抓，不仅费时费力，而且往往结果不理想。本文当然不是把阿里云的所有相关产品拿出来介绍一遍，而是围绕一个典型的DevOps流水线展开。
上图是一个云原生下的比较典型的DevOps流水线，从这个流水线入手来分析，主要是研发和交付两个视角:
1. 研发视角
云原生应用研发基本都是围绕微服务展开，涉及到微服务架构设计、代码研发、单测，当然还包括编写打镜像需要的配置文件（简单理解可以认为是写dockerfile）、以及使用基础设施平台进行发布和运维操作等等。
1.1 微服务研发
首先自然是需要一个代码仓库，据调查gitlab已经占有一半以上的自托管市场，结合gitlab ci和gitlab runner的使用，只需几个脚本就能串联起一套简易的自动化流水线。本文假设已经选择了gitlab作为代码管理平台。
搞定了代码仓库，回到微服务架构，主流的springcloud技术体系当仁不让，当netflix不再维护开源组件之后，spring cloud alibaba 恰逢其时的填补了所有空缺，上图是spring cloud微服务架构相关的组件对比，从服务注册发现、路由、调用、熔断，到负载均衡、分布式消息、分布式事务、以及分布式配置，可以说是方方面面都能支持。特别是即将发布的dubbo 3.0，面向云原生的改造之后，不仅其服务模型已经和主流微服务模型（spring cloud，k8s native service）对齐，而且在协议层面做了大量的改造，可以简单认为dubbo3是Dubbo和HSF的融合。基于dubbo3的研发实战后续文章会陆续深入，这里不再累述，有兴趣可以点图片下面链接查阅dubbo3.0前瞻。
图片来自：developer.aliyun.com/topic/downl…
上述微服务框架组件可以根据偏好自主选择，并不是说基于阿里云落地云原生必须选择spring cloud alibaba提供的组件。另外，对于微服务的研发涉及到的各种模式和细节会在后续文章陆续更新，本文点到为止.
1.2 镜像化改造
落地云原生，镜像化改造是必不可少的一步，这也是上容器服务的基础。
- 创建镜像
a）使用dockerfile
创建简单的 Docker 镜像并不复杂，只需要编写描述镜像内容的 Dockerfile 文件，再使用 docker build 命令来创建镜像即可。下面是一个例子：
FROM adoptopenjdk/openjdk8:jre8u262-b10-alpine
ADD target/nacos-discovery-consumer-sample-1.0.0.jar /opt/app.jar
ENTRYPOINT [ "java", "-jar", "/opt/app.jar" ]
然后使用docker命令创建和本地运行镜像：
$ docker build . -t local/nacos-discovery-consumer-sample:1.0.0
$ docker run local/nacos-discovery-consumer-sample:1.0.0
或者，有了dockerfile之后使用maven插件更加方便，在package过程中打包完jar之后使用exec-maven-plugin 插件来调用 docker build 命令
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>docker</executable>
<arguments>
<argument>build</argument>
<argument>.</argument>
<argument>-f</argument>
<argument>${project.basedir}/src/docker/Dockerfile</argument>
<argument>-t</argument>
<argument>${project.artifactId}:${project.version}
</argument>
</arguments>
</configuration>
</plugin>
b）使用 Spring Boot 的 Buildpacks
Spring Boot 从 2.3.0 版本开始，支持使用 Buildpacks 来创建 OCI 镜像。在 Maven 中，只需要使用 Spring Boot Maven 插件的 build-image 命令即可，基本用法如下：
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>build-image</goal>
</goals>
</execution>
</executions>
</plugin>
c）使用 Jib
Jib是由 Google 维护的工具，用来对 Java 应用进行容器化。其优势在于不需要依赖 Docker 守护进程，就可以创建出 OCI 容器镜像，构建镜像也不需要编写 Dockerfile。Jib 会自动把应用分成多层，把应用依赖的第三方库和应用自身的类文件分开。
- 镜像服务 ACR
有了镜像之后，还需要镜像仓库来存储和分发。这里推荐一下阿里云镜像服务ACR，作为云原生应用制品管理平台，提供容器镜像、Helm Chart，符合OCI规范制品的生命周期管理；支持大规模、多地域、多场景下应用制品的高效分发；也可以与阿里云自家的容器服务ACK无缝集成，帮助企业降低交付复杂度。配置完镜像仓库、代码源、访问控制等一些基本的规则之后，即可实现代码提交自动打镜像上传的任务。
2. 交付视角
现在可以开始交付了，这里跳过了UT和各种测试以及修bug的过程。
1）K8S 集群
Kubernetes早已是云原生容器编排领域的标准，谷歌的目标是将其打造云原生操作系统，这在上一篇云原生文章有详细阐述。那么如何选择Kubernetes集群呢？基于阿里云来落地来说，ACK是一个不错的选择，特别是对于之前就跑在阿里云ECS的用户来说，ECS资源可直接作为节点让ack集群管理起来。ACK有三种可选方案：专有版Kubernetes（Dedicated Kubernetes）、托管版Kubernetes（Managed Kubernetes）、Serverless Kubernetes。
上图来自 help.aliyun.com/document\_d…
据神雕了解，有蛮多中小公司选择托管版k8s，特别是应用规模不大的情况下，其标准版不仅运维简单，而且只需承担购买ECS等基础资源的费用。当然k8s集群是非常复杂的，感兴趣可以去认真学习下ack集群各方面的功能，对个人在k8s集群相关技术的提升有很大帮助。
2）发布部署
有了集群之后，现在就可以发布微服务应用了。方式有多种，回归到底层k8s，无论是简单的副本集发布，还是滚动部署deployment，原理上都是下发yaml文件。原则上有三种方法:
a) 手动kubectl 搞起来
b) 自己基于k8s接口搞一套适合自己的工具
c）使用开源组件串联起来
d) 使用第三方工具白屏化搞起
根据动手能力，从前三种a/b/c方案搞起来就行。当然手动kubectl比较适合个人学习或者应急的场景。据神雕了解，有部分创业公司使用gitlab中安装和注册gitlab runner，通过在项目中编写CI/CD脚本来达到发布运维能力。也有使用helm chart来满足更加复杂的部署场景。 接下来介绍两种d方案。
既然上文选择了ACK，那么很自然可以使用ack的控制台来发布部署，支持无状态服务、有状态服务、定时任务等。对于微服务架构，绝大部分都是无状态服务，状态只会收敛在少数几个缓存或者DB服务里。而对于这些有状态服务，云原生落地的原则是推荐使用云上的存储服务，而不是自己来部署运维。以无状态服务为例，根据镜像发布，需要填写发布副本数、发布的镜像、资源配额(多少CPU，多少内存)、服务开启的端口、环境变量、前后置处理等。如果需要对外提供服务，还需要配置对应的service。
除了ACK 之外，另一个选择是EDAS，当然仅仅用它来做发布部署有点浪费了。EDAS全名 Enterprise Distributed Application Service，其实是阿里云提供的一个应用托管和微服务管理的云原生PaaS平台，提供应用开发、部署、监控、运维等全栈能力。同时支持dubbo和springcloud等微服务运行环境，可认为是上云的助力神器，当然收费也不便宜。个人研发学习有5个POD的免费使用配额。
3）可观测性
云原生微服务化架构讲究可观测性，自下而上分别是：基础设施层、容器性能层、应用性能层、用户业务层。
基础设施层可观测性是指容器服务所依赖的底层资源的可观测场景：定位Pod与节点组成的资源池的调用链路，可视化拓扑关系，以及基础设施监控，例如宿主机节点、网络基础组件的性能监控等。有两种可选方案，一是使用AHAS（Application High Availability Service）云产品提供的架构感知产品能力，能自动感知POD的拓扑关系和调用关系，防护系统流量做大高可用，二是使用Cloud Monitor来监控资源负载的CPU/内存/网络等指标。
容器性能层可观测性是指容器抽象层的可观测场景，包括集群的性能、事件等监控，容器的性能，以及容器组件等监控。方案有三：一是用cloud monitor来监控，二是使用阿里云托管版本Prometheus，三是开源Prometheus监控方案，阿里云容器服务在应用市场中提供了开源Prometheus监控方案的集成（help.aliyun.com/document\_d…
应用性能可观测性包括应用指标性能（Metric）、系统调用链（Tracing）、日志监控（Logging）等，例如基于容器服务构建一个JAVA应用，JAVA应用的线程数指标等。可选无侵入应用监控APM监控方案或者侵入应用监控APM监控方案，前者使用阿里云ARMS产品，后者可使用Tracing Analysis。
用户业务可观测性是指用户自定义的具体业务场景，例如基于容器服务构建一套高可用可扩展的网站，网站的业务运营数据PV、UV等，例如应用的成本审计场景等。可以使用阿里云日志服务SLS （Log Service）作为自定义指标的观测方案。
3. 状态处理
最后剩下云原生最难处理的一趴：应用状态。前文所述基本都是基于这样一个假设，我们的微服务开发基本满足12Factors，整个业务的状态是收敛在有限的数据库或者缓存服务，而应用服务本身都是无状态的。那么，这些有状态服务该如何选择呢？
-
每个微服务都应该拥有自己的数据库
-
每个微服务都需要一个缓存
-
使用事件日志让微服务之间更加松耦合
那么，数据库有什么方案？缓存有什么方案？消息有什么方案？
诚然，数据是企业的核心资产，我们都在追求可靠可扩展可维护的系统，背后离不开分布式数据系统的支撑。自己搭建和维护一套分布式数据系统不是说不可以，而是性价比太低，且不说维护一套高可用、高性能、可扩展的分布式数据系统的复杂度较高，而且在整体朝云原生方向去落地过程中，自己搞一套数据系统和云平台打通或多或少增加网络的复杂性。正因为如此，云原生首选推荐方案是使用云上的数据服务，而不是自己来搭建和维护。数据库类型的选择依然是根据业务类型特征评估。
上图是现代应用一个典型架构包含多个不同的数据服务组件，总结一下大概会涉及到关系数据库、键值对数据存储、文档型数据库、消息队列、搜索引擎这些种类。
上图阿里云数据库产品的一个目录截图，发现云上数据服务非常丰富，基本满足各种需求，不做一一阐述，下面简单介绍几款比较亮眼的产品。
1）两款阿里云云原生数据库
PolarDB 是阿里巴巴自主研发的下一代关系型分布式云原生数据库，目前兼容三种数据库引擎:MySQL、PostgreSQL、高度兼容 Oracle 语法;计算能力最高可扩展至 1000 核以上，存储容量最高可达 100T。PolarDB 经过阿里巴巴双十一活动的最佳实践，让用户既享受到开源的灵活性与价格，又 享受到商业数据库的高性能和安全性。
PolarDB-X(原 DRDS 升级版)是由阿里巴巴自主研发的云原生分布式数据库，融合分布式 SQL 引擎 DRDS 与分布式自研存储 X-DB，专注解决海量数据存储、超高并发吞吐、大表瓶颈以及复杂计算 效率等数据库瓶颈难题，历经各届天猫双 11 及阿里云各行业客户业务的考验，助力企业加速完成业务数 字化转型。
2）两款阿里云云原生大数据
云原生数据仓库 AnalyticDB MySQL 版(简称 ADB，原分析型数据库 MySQL 版)是一种支持 高并发低延时查询的新一代云原生数据仓库，全面兼容 MySQL 协议以及 SQL:2003 语法标准，可以对 海量数据进行即时的多维分析透视和业务探索，快速构建企业云上数据仓库。产品规格按需可选，基础 版成本最低，适合 BI 查询应用;集群版提供高并发数据实时写入和查询能力，适用于高性能应用;弹性 模式版本存储廉价按量计费，适用于 10TB 以上数据上云场景。
云原生数据仓库 AnalyticDB PostgreSQL 版，支持标准 SQL 2003，兼容 PostgreSQL / Greenplum, 高度兼容 Oracle 语法生态;具有存储计算分离，在线弹性平滑扩容的特点;既支持任意 维度在线分析探索，也支持高性能离线数据处理;是面向互联网，金融，证券，保险，银行，数字政务， 新零售等行业有竞争力的数据仓库方案。
3）阿里云消息产品
消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可 靠的分布式消息中间件。该产品最初由阿里巴巴自研并捐赠给 Apache 基金会，服务于阿里集团 13 年， 覆盖全集团所有业务，支撑千万级并发、万亿级数据洪峰，历年刷新全球最大的交易消息流转记录。
消息队列 Kafka 版是阿里云基于 Apache Kafka 构建的高吞吐量、高可扩展性的分布式消息队列服 务，广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等，是大数据生态中不可或缺 的产品之一，阿里云提供全托管服务，用户无需部署运维，更专业、更可靠、更安全。
消息队列 AMQP 版由阿里云基于 AMQP 标准协议自研，完全兼容 RabbitMQ 开源生态以及多语 言客户端，打造分布式、高吞吐、低延迟、高可扩展的云消息服务。
微消息队列 MQTT 版是专为移动互联网 (MI)、物联网 (IoT) 领域设计的消息产品，覆盖互动直播、 金融支付、智能餐饮、即时聊天、移动 Apps、智能设备、车联网等多种应用场景;通过对 MQTT、 WebSocket 等协议的全面支持，连接端和云之间的双向通信，实现 C2C、C2B、B2C 等业务场景之 间的消息通信，可支撑千万级设备与消息并发，真正做到万物互联。
阿里云消息服务 MNS 是一种高效、可靠、安全、便捷、可弹性扩展的分布式消息服务 , 能够帮助应 用开发者在他们应用的分布式组件上自由的传递数据、通知消息，构建松耦合系统。
事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务，支持阿里云服务、自定义应用、 SaaS 应用以标准化、中心化的方式接入，并能够以标准化的 CloudEvents 1.0 协议在这些应用之间路 由事件，帮助用户轻松构建松耦合、分布式的事件驱动架构。
4. 简单收个尾
落地云原生有多种选择和姿势，而且随着技术迭代和演进，会有越来越多的方法可供选择。本文介绍的一些方法只是其中很小的一部分，记住一条主线：代码仓库(gitlab)、微服务开发(spring cloud)、镜像化改造(docker)、镜像仓库(ACR)、容器服务平台(ACK)，以及系统部署之后的各种可观测性能力。最后是微服务状态收敛到的数据服务产品的介绍和选择。
