作者： 孤弋（李颜良）
从几个数字开始说
IDC 预计到 2024 年，由于采用了微服务、容器、动态编排和 DevOps 等技术，新增的生产级云原生应用在新应用的占比将从 2020 年的 10% 增加到 60%，其中微服务的 workload 在企业内将超过 80% 。上面的四点是云原生时代所代表的四个核心技术。其中，我们的开发同学可能对于微服务比较热衷，从近几年的趋势来看，Java 领域的微服务框架日趋成熟，和云原生的结合也越来越紧密。从 EDAS 中的数据来看，Spring Cloud + Kubernetes 基本上已经成为了微服务架构形态下的主流配搭。但是另外一个数据让我产生了更多的好奇，就是目前在云原生场景下有过微服务生产经验的开发人员不足 8% 。为什么会是这个样子？我觉得主要原因有两个：
首先，是因为本身微服务的学习曲线比较陡峭，好不容易学会精通一个框架，可以进行生产实践了，可是马上又面临了云原生诸多复杂的概念和复杂环境搭建的技术挑战，这个两个因素结合在一起对于每一个人充满的都是对于未知世界的恐惧，这样在一些战略定力不那么强的团队中，最后落地效果就不太好。
针对这一条，我觉得大家只需要跟进我们团队的一些产品和相关课程就行了，云原生团队有大量的相关课程在阿里云大学上供大家学习，很多产品也提供了不错的工具；同时在各个领域都有很多的数字化转型的经验，其中包括微服务在研发团队中践行落地的经验。感兴趣的伙伴可以给我们留言，我们可以择期进行深入的沟通交流。
其次，对于开发人员而言，一直有一个错误的认知就是云原生应用和普通开发的应用是没有区别的，因为对于开发者而言，还是一样写代码，还是一样发布部署，还是一样排查诊断。但是这里还真的不太一样，哪里不一样呢？Heroku 给我们总结出来了 12 条要素，在圈内叫做 12 factor apps，既简单理解下来，符合这个十二条要素的应用，才能叫做云原生应用。
Twelve Factor Apps
这个十二条我列在了这里，橙色的部分，和我今天的内容相关。下面我每一条做一下简单的讲解：
第一条：Codebase，既一份代码，多处部署。反过来理解就是多个部署都是一份代码，而且 得 是一份代码。那什么时候不是？比如我们直接上生产环境中调整但是忘了同步回来的时候，也就是说，这一条是约束我们的研发流程，保证代码在各个环境中的一致性。
第二条：是显示声明依赖关系，这一条很好理解，写 Java 的同学都会使用 ant、maven、gradle 这样的工具对于一些依赖进行显示声明。但是我们往往容易忽略两点，第一点，是依赖一个 snapshot 版本，最后因为缺少有效的跟踪而导致线上故障。第二点是一个隐含的依赖，既代码运行时环境的依赖系统软件、执行引擎等应都当是做应用的一部分。
第三条：Config，常规理解是代码配置分离。这里严格意义上，是讲的是整个运行环境（镜像）与配置要做隔离，什么意思呢？这里的核心是所依赖配置，是否能在运行启动的过程中，通过常规的运维手段能进行灵活替换，这些运维手段包括：比如更改环境变量，更改启动参数，通过分布式配置服务等。
第四条：Backing Services，所有后端服务，其实包括所有发生网络调用的情形，我们都需要同一视角去对待。当作附加资源有两种意思，第一是资源应当准的资源访问的接口与方式，比如在 Java 中的 URI 接口。还有一种理解就是既然是资源，就需要考虑他的可用性，既然所有后端服务都是资源，那么我们也要一视同仁的去治理资源的可用性。
第五条：Build,Release,Run 之所以要严格分开，这是三个领域我们关注的能力也会不一样。首先 Build 更注重实效；而 Release 要注重策略；Run 阶段更注重流量治理，要尽可能的做到流量无损耗。
第六条：Stateless，单纯进程维度的无状态主要是进程启动过程中对于数据的依赖。无状态的目的，是为了更好的做快速伸缩甚至自动的弹性伸缩，Stateless + 启动无需干预是弹性的关键一步。
第七条：Port Binding，是指所有对外暴露的服务都通过端口暴露，这里是与之相反的是有一些应用通过 unix socket 或者 IPC 之类的访问方式会极大增加大规模服务运维场景下的复杂度。
第八条：Processes，这里的理念其实是当服务容量需要弹性时，推荐使用 Scale out，而非进程内的 Scale up，Scale Out 能使应用最大化的利用各种规格下的系统资源，而 Scale Up 的对于 JVM 类似的机制而言，往往会带来额外的系统开销和更复杂的 GC 策略。
第九条：Disposability，快速启动的场景我们应该拉长来看，回到第五条的 Run 阶段，Run 阶段应该从一个全新的环境准备好开始到进程真正拉起开始服务为止，即包括环境准备、程序包拉取，也包括进程启动后续的所有流程。而优雅终止则容易忽略类似于消息、调度任务、线程池等后台任务的处理。
第十条：Dev/Prod parity ，理解容易，落地比较困难。要达成这一点的前提，理论上是要避免一切在环境中人为的操作。云原生中有一条叫做“不可变基础设施”，其实和这一条在对应，但是不可变基础设施指的在运行时需严格 follow 在代码中声明的配置，如果要变则需要重新声明。
第十一条：Logging Event，是推荐日志当成事件流处理，确切的说就是建议将所有日志都打印到标准输出中，而不是使用配置文件。同时使用专门的集中存储的日志服务把日志内容收集然后统一进行聚合、清理、查询。这样不仅运维标准简单。而且可以解耦本地磁盘依赖，云原生场景下的应用，要做好磁盘数据随时可能消失的准备。
第十二条：后台管理任务指的是一些维护性质的任务，比如清理日志、缓存、订正某些数据等等。我们应该把这些都当成本身业务的一部分，不能游离在整个产品体系之外。既同样需要遵循前面 11 条，如：一份代码，显示声明，代码和配置解耦，无状态等等。
常规开源软件方式搭建
首先，是需要准备一个微服务环境，最为基础的在微服务场景下需要一个服务注册发现的组件（如：Nacos），当然随着我们的业务越来越复杂，需要的组件肯定会越来越多比如：APM 组件、日志服务组件等等。
然后，我们本地会使用一个 IDE，搭建代码工程，开始进行开发。在 Java 中，使用 mvn 进行依赖包的管理。
第三，我们将代码提交到 git 仓库中，所有针对环境变更的操作，都应该遵循 Build/Release/Run 的流程严格区分开。现在 Jenkins 可以很好的达到这个效果，在在 Jenkins 中创建一条流水线包含多个任务，分别是：程序构建变异、构建镜像。镜像上传；最后针对 K8s 的发起一次对应的 workload 的变更。
EDAS Core 将开源四步变成一步
EDAS 团队提供了一种更简便的方式，它是产自于阿里云云产品 EDAS 的一个简单的实现，包括 EDAS 中的部分应用周期管理和微服务治理能力，且自带 webshell，他最简化的安装只需要 4C8G。它轻量、简便，笔记本上可拉起，也可安装在任意一套标准的 K8s 集群上，可免费用于开发测试。可以将上述步骤四步变成一步：
安装步骤
第一步，我们先将 EDAS Core 的安装包下载，并解压。
第二步，将确认好集群相关的 kubeconfig 文件并放至对应的位置。
第三步，进入到安装目录并执行安装脚本，整个过程大概历时 7-8 分钟。
使用 EDAS Core 无需准备复杂的 Dockerfile 和镜像，只需要依次选择相对应的环境，并上传常规的程序包上传并设置相应的规则参数就好了。而且微服务相关的 Nacos 组件搭建、地址参数配置等都会默认管理好。
同时使用 EDAS 也做了一个官方 Jenkins 插件专门用来和 Jenkins 对接，只需要在插件中提供 EDAS 应用 ID，和部署包的地址。就可以完成流水线的对接。
微服务开发下的痛点
环境搭建只是第一步，微服务的开发中，其中一个痛点是一个系统是自己开发的应用，如何加入到一个原来大的生态集群中。以及两个应用需要同步上线一个新的能力，如何在不影响别人的情况下，这个两个人可以根据一定流量规则进行精准联调。如下图：
端云互联
为了解决上面的两个问题，我们推荐给您的是 Alibaba Cloud Toolkit 中的《端云互联》功能，在这个方案中只需要提供一台 ssh 端口能联通的跳板机就能很完美的解决上面两个问题：
同时在精准联调的场景下，可以在 EDAS 中创建一个泳道组并指定好入口应用，在云上设置好流量规则。同时让两个开发人员同时加入到这一个泳道组中。随后所有满足规则的流量则会精准的路由到彼此的节点上。
不仅如此，Cloud Toolkit 中还提供了另外一个能力是可以直接从 IDE 中一键部署到环境中，也提供了一键进入 POD 的 Webshell 能力，方便我们进行排查诊断，此能力近期也会上线在 EDAS 商业版本中。
当我们把所有的应用都开发好了之后，我们要面对很多新的环境的准备，比如我们要准备新的测试环境、压测环境、预发、生产 等等，运维同学每一次准备环境的过程都会随着应用的增多而备受煎熬。EDAS Core 针对这种场景，特开发了一键将所有应用上云的功能。
最后的彩蛋：成都环境推出免费版本
为了打消上云之后有的同学会担心所花费的商业版本的费用的顾虑，EDAS 在 8 月底的时候，在成都环境公测了一种新的应用形态，这种形态下 EDAS 将管控、微服务治理、APM 监控三个能力进行了分拆，大家可以根据自己的需要灵活定制，欢迎大家试用反馈。
