部分一我是一名软件工程专业大三的学生，原本就想添加一个博客项目（因为每次去找自己写的笔记很麻烦，文件夹一个套一层 哎~。准备全部整合好，放在博客上方便自己查找）所以就一直在挑选合适的服务器。直到发觉来很多同学推荐，才发现阿里云ECS飞天加速计划。认真体验了阿里云的服务，从刚接触的些许生疏到熟练地上手的意外的迅速，对于新手来说那是相当的友好。使用过后不得不赞叹其种种优越性。帮我解决了在硬件上的不便之处和减少了很多后顾之忧。对此非常感谢阿里云活动的开展。部分二作为一名软件工程的学生，对于服务器方面的知识了解较少。阿里云的活动帮我省去了一些成本上的忧虑，填补了我在相关方面知识的空缺（增加了我相关领域的经验也让我了解到了liunx和docker），对于我而言领取ECS主要是用来搭建一个个人博客，在这么多天的学习中也了解一些关于部署的相关知识。我是前台用的技术栈为 Spring Boot + Vue + Mysql + MyBatisPlus + Redis 是一直跟着三更up主的视频在做因为up主还没有更新后台，所以我自己就使用若依来搭建后台（当然也是前后端分类的版本）就这样一个小小缝合网站就出现了。在学习微服务之后也准备吧网站拆分服务用来练习，这样就更离不开云的使用。帮我整合了全部学习到的知识，个人非常满足。能让我接触到这种云服务器。部分三这几天的使用真的让我体会到ECS，以前由于成本和硬件上面的关系导致使用虚拟据经行作业感到非常崩溃（经常搞IP怎么都ping不上，我也能感觉我的笔记本在跑一个虚拟机的无力，飞天加速计划终于让我没有这种烦恼了）。最后再次感谢飞天加速计划，给我的小小网站展示的机会。

　　Monorepo是一个新的名词，但不是一个新的概念。从软件开发最开始，我们已经在开始用这种模式了。这种模式的一个中心思想就是，用一个repo来管理所有的源代码。除了这种模式以外，另一个比较受推崇的模式就是multirepo,也就是用多个repo来管理自己的源代码。　　不需要深刻思考这两种模式，各有利弊。今天我们来分别说一下这两种模式,但会着重来讲使用Monorepo可能会遇到的问题。　　现在比较大型的软件开发公司，比如说Google, Uber, Netflix他们都在使用monorepo。但是对于我们中小型公司或者个人开发者来说，到底需不需要用monorepo,还是选择multirepo?　　好，我们就现在具体谈一下monorepo。在这种模式下，你所有的设计文档，所有的源代码，所有的所有都放在一个repo里面。这样做的好处有这些:　　你的一次提交可以解决所有的问题。　　这个提交可以是添加一个功能，修改一个bug，这个功能添加或者代码修改会涉及很多不同的模块儿，这些模块都可以在一个change request里面做完。　　因为所有的这些修改都在一个repo里面，这样你查找历史，查看这些修改之间的关联都比较容易。　　当然了，这个好处的获取需要所有的程序员和文档提交者都遵循一个统一的格式。　　另一个好处，是所有的人都有访问权限。这样就杜绝了权限申请方面的种种问题。不存在这些代码，某些人看不了的问题。整个开发团队里面没有任何秘密。　　好，上面说了monorepo的好处, 那为什么现在很多人都在用multirepo呢?　　现在就来说说monorepo的坏处。　　Monorepo, 一个最大的问题就是随着程序规模的不断增加，代码量的增加，文档的增加，整个repo会变得越来越大。　　我以前做过一个Nike的项目, 那个项目使用的就是monorepo的模式。那个repo当时的大小是21g。怎么样？你的小心肝还能承受得住吧？　　试想一下，一个程序员只想改一下其中的一个翻译文字，你就需要把这21G大小的整个repo都拿到你的本地来。这个过程一定是欲仙欲死的。现在使用multirepo的人一定会对你说good luck。　　另一个坏处也是上面说的好处，就是权限访问的问题。Monorepo模式下的权限是开放的。代码安全，文档安全，都会是一个需要好好考虑的问题。　　这个方面如果处理不好的话，对整个团队整个项目带来的后果可能是灾难性的。　　像google这样的大公司他们都用自己的代码管理系统，那一个程序员要修改一个模块的代码的时候，他需要把所有的项目代码都下载到本地来，并获取最新的代码。做一个修改以后，check in完成就会进行整个项目的编译。整个项目可能需要两个小时的编译时间，这个时候，这个程序员可以跟别人聊聊天，可以学点东西，这也是很好的一种程序员生活。在monorepo的开发模式下，这是一个非常常见的工作状态。　　为了对这些修改做好标志，每一次一些标志性的修改都会添加一个版本号。对应一个版本号都会有一个版本历史。对应每个版本号又会有一个对应的标签。大部分时间我们只对最新的版本感兴趣。　　接下来我们来看一下multirepo, 在这种模式下，你很少见到一个非常庞大的代码库或者文档库。但这不能说这种模式，就是完美的。它还会有别的其他的问题。　　这种模式的总的设计是一个把一个大的问题分成几个小的问题来解决。通过问题的细化，减少整个问题解决的复杂度，从而让自己的工作更加顺手，更加有保障。　　上面这个设计是不是听起来很熟悉，对了， 它跟微服务架构是一个理念。　　通过这个分解，每一个小部分作为一个单独的repo。每个repo,可以分给不同的小组来开发和管理。每个小组只需要关心这一小部分工作就可以了。每一个小的部分都可以单独的进行买酒测试和开发。这个是好的一个方面。　　下面来说一个坏的方面。因为每个小组可以各自为战。这样就给协同工作带来很大的问题。比如说一个小组的模块进行了升级，导致现有的大系统其他模块儿无法正常工作。这种现象在微服务架构系统的开发中非常常见。　　如果把这个坏的方面再发挥到极致，就是每个组件之间互相依赖互相破坏，这样子你整体系统可能就陷入万劫不复的深渊。也就是说，随着微服务架构，继续把模块儿进细化，每个模块失去了紧密的联系，与此同时又没有很好的管理机制把握全局， 导致整个项目开发失去了控制，这也是很多微服务架构系统失败的原因。　　所以在multirepo的开发过程中，非常重要的一点就是避免过度的细分。一定要有一个机制来把握全局，时刻监控整个开发环境是否正常。　　制定标准是一个很有意思的话题， 虽然说技术上很难争高下, 但是总会辩论出一个最好的方案来，但是最严重的有时候根本不是技术上的问题。这个里面就会有很多说不清道不明的问题了。　　就因为如此，在一些大公司当中，因为人员的素质都比较高，都是高手，常言说一山不容二虎，这里山中有好几只，几十只老虎。在这种情况下，用一只老虎的标准来把握全局是很难的。　　所以宁愿牺牲一些下载时间，编译时间上的代价，最终他们还是继续使用monorepo的模式。　　还有一个在multirepo中不可忽视的一个问题就是为了保证一个功能的完整运行, 即使再小的改动，也有可能对所有的repo进行更新。这是一个非常烦人的过程。　　我工作过的一个multirepo项目，它里面有20多个模块。要想使整个系统工作完整，你需要把这20多个模块都下载到本地来，当然，你可以采用一些比较简洁的方式，比如说docker container的image, 尽可能的减少与过多的模块儿直接的接触。在这种模式模式下我相信你是非常喜欢黑盒模式的。因为模块太多，你根本不想搞清楚它里面到底在干什么。只要能给你工作就行了。一个是太烦人，另外一个是时间太紧张了。　　那么现在的问题就是，上面两种模式哪种更好呢？我的观点是，不管你喜欢哪种模式，选择哪种模式，他们都是你的工具，你要控制他们，而不是他们控制你。　　这种模式的本意都是想让你的工作做得更好。　　Monorepo你需要做的是尽可能的把你的测试案例细分开。这样你在提交一个修改的时候，就不需要把所有的测试都过一遍，那样太费时间了。　　Multirepo对于你自身模块的测试案例，你需要做的是把与你的模块相关的测试案例都放进来。在你提交一个修改的时候，要保证所有的这些案特殊案例都通过。如果需要下载相关模块的修改更新，要尽快通知大家去下载。　　一个很常用的模式是这两种模式的结合。你比如说一个修改，你可能需要修改很多个repo， 那你可以考虑把这多个repo合成一个。　　这个话题还有很多要可以谈的，我们这一期就先谈这些吧。

为什么有了无损下线，还需要无损上线？无损上线可以解决哪些问题？本篇文章将一一回答这些问题。无损上线功能不得不说是一个客户打磨出来的功能我们将从一次发布问题的排查与解决的过程说起。背景阿里云内部某应用中心服务在发布过程中出现了大量的5xx超时异常。初步怀疑是无损下线问题，于是很快便接入了 MSE 提供的无损下线功能。但是接入无损下线功能后继续发布，应用的发布过程依然存在大量的超时报错。根据业务方同学的反馈，大概应用在启动后 5秒左右，会有大量超时请求。无损下线功能未生效？于是拉了相关的同学开始排查。应用的调用情况如下： gateway - > A -> C 。发布的应用为 C 应用，发布过程中出现大量超时报错。我们通过相关日志与应用的启动情况，整理如下线索【服务端视角】：找了一台 C 应用的机器 xxx.xxx.xxx.60 观察 第一阶段 xxx.xxx.xxx.60 (C应用)下线阶段20:27:51 开始重启，执行重启脚本同时观察到执行了 sendReadOnlyEvent 动作，表明服务端发送只读事件，客户端不会再请求该服务端在 sendReadOnlyEvent 后，开始陆续执行注销服务动作20:27:54 注销所有 provider seivce 完成20:28:15  应用收到 kill -15 信号第二阶段 xxx.xxx.xxx.60 (C应用)上线阶段20:28:34 服务端重新启动20:29:19 在Dubbo注册中心控制台观察到 xxx.xxx.xxx.60 注册完毕20:29:19,257 日志中看到 start NettyServer 【客户端视角】：找了一台 A 应用的机器 XXX.XXX.XXX.142 观察20:27:51 received readOnly event，收到服务端发送的只读事件，此时该客户端不会请求至 XXX.XXX.XXX.60 机器20:27:56 close [xxx.xxx.xxx.142:0 -> /XXX.XXX.XXX.60:20880] ，关闭channel连接业务日志报错信息同时搜C应用的机器 XXX.XXX.XXX.60的报错相关的日志，共237条日志其中最早的time:  2020-07-30 20:29:26,524 其中最晚的 time:  2020-07-30 20:29:59,788结论观察这些迹象可以初步得出结论无损下线过程均符合预期，并且下线过程中并没有出现任何报错报错期间处于服务端应用成功启动后且注册成功后，与业务方观察的现象一致这时候怀疑是上线期间的问题，同时排查服务端相关日志，发在报错期间，服务端线程被打满问题定位为上线过程中的问题，与无损下线无关无损上线实践我们帮助用户解决问题的思路：帮助用户发现问题的本质、找到问题的通用性、解决问题、将解决通用问题的能力产品化。发现用户dubbo版本比较低，缺少自动打线程堆栈的能力通过MSE 增加Dubbo线程池满自动 JStack 能力这是每次发布必现的问题，通过观察线程池满时的 JStack 日志，有助于我们定位问题。阻塞在异步连接等资源准备上初步观察 JStack 日志，发现不少线程阻塞在 taril/druid 等异步连接资源准备上同时我们云上也有有客户遇到过，应用启动后一段时间内 Dubbo 线程池满的问题，后经过排查由于 Redis 连接池中的连接未提前建立，流量进来后大量线程阻塞在 Redis 连接建立上。连接池通过异步线程保持连接数量，默认在应用启动后 30 秒建立最小连接数的连接。解决思路提前建立连接使用服务延迟发布特性预建连接以 JedisPool 预建连接为例，提前建立Redis等连接池连接，而不是等流量进来后开始建立连接导致大量业务线程等待连接建立。org.apache.commons.pool2.impl.GenericObjectPool#startEvictor protected synchronized void startEvictor(long delay) { if(null != _evictor) { EvictionTimer.cancel(_evictor); _evictor = null; } if(delay > 0) { _evictor = new Evictor(); EvictionTimer.schedule(_evictor, delay, delay); } }JedisPool 通过定时任务去异步保证最小连接数的建立，但这会导致应用启动时，Redis连接并未建立完成。主动预建连接方式：在使用连接之前使用 GenericObjectPool#preparePool 方法去手动去准备连接。在微服务上线过程中，在初始化Redis的过程中提前去创建 min-idle 个 redis 连接，确保连接建立完成后再开始发布服务。JedisPool warm-internal-pool同样有类似问题，预建数据库连接等异步建连逻辑，保证在业务流量进来之前，异步连接资源一切就绪。延迟发布延迟发布为了一些需要异步加载的前置资源如提前准备缓存资源，异步下载资源等，需要控制服务注册时机，即控制流量进入的时机保证服务所需的前置资源准备完成该服务才可以进行发布，延迟发布有两种方式通过 delay 配置方式通过指定 delay 大小例如 300 s，Dubbo/Spring Cloud 服务将会在 Spring 容器初始化完成后进行后等待 5 分钟，再执行服务注册逻辑。online 命令上线通过打开默认不注册服务配置项，再配合发布脚本等方式执行 curl 127.0.0.1:54199/online 地址触发主动注册。我们可以在前置资源准备完成后，通过 online 命令去注册服务。也可以在 MSE 实例详情通过服务上线去注册服务。阻塞在 ASMClassLoader 类加载器上大量线程阻塞在 fastjson 的 ASMClassLoader 类加载器加载类的过程中，翻看 ClassLoader 加载类的代码其默认是同步类加载。在高并发场景下会导致大量线程阻塞在类加载上，从而影响服务端性能，造成线程池满等问题。private ClassLoader(Void unused, ClassLoader parent) { this.parent = parent; // 开启并行类加载 if (ParallelLoaders.isRegistered(this.getClass())) { parallelLockMap = new ConcurrentHashMap<>(); package2certs = new ConcurrentHashMap<>(); domains = Collections.synchronizedSet(new HashSet<ProtectionDomain>()); assertionLock = new Object(); } else { // no finer-grained lock; lock on the classloader instance parallelLockMap = null; package2certs = new Hashtable<>(); domains = new HashSet<>(); assertionLock = this; } } protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { ...... return c; } } protected Object getClassLoadingLock(String className) { Object lock = this; //如果开启类加载器并行类加载，则锁在所加载的类上，而不是类加载器上 if (parallelLockMap != null) { Object newLock = new Object(); lock = parallelLockMap.putIfAbsent(className, newLock); if (lock == null) { lock = newLock; } } return lock; }解决思路开启类加载器并行加载类加载器开启并行类加载JDK7上，如果调用Classloader.registerAsParallelCapable方法，则会开启并行类加载功能，把锁的级别从ClassLoader对象本身，降低为要加载的类名这个级别。换句话说只要多线程加载的不是同一个类的话，loadClass方法都不会锁住。我们可以看 Classloader.registerAsParallelCapable 方法的介绍protected static boolean registerAsParallelCapable()Registers the caller as parallel capable.The registration succeeds if and only if all of the following conditions are met:1. no instance of the caller has been created2. all of the super classes (except class Object) of the caller are registered as parallel capable它要求注册该方法时，其注册的类加载器无实例并且该类加载器的继承链路上所有类加载器都调用过registerAsParallelCapable，对于低版本的Tomcat/Jetty webAppClassLoader 以及fastjson的ASMClassLoader都未开启类加载，如果应用里面有多个线程在同时调用loadClass方法进行类加载的话，那么锁的竞争将会非常激烈。MSE Agent 通过无侵入方式在类加载器被加载前开启其并行类加载的能力，无需用户升级Tomcat/Jetty，同时支持通过配置动态开启类加载并行类加载能力。http://140.205.61.252/2016/01/29/3721/其他一些问题JVM JIT编译问题引起cpu飙高日志同步打印导致线程阻塞Jetty 低版本类加载类同步加载K8s场景下，微服务与K8s Service 生命周期未对齐解决思路服务预热客户端负载均衡服务端服务分层发布业务日志异步化提供微服务 Readiness 接口业务日志异步化同步进行日志打印，由于日志打印使用的是业务线程，由于日志打印过程中存在序列化、类加载等逻辑，在高并发的场景下会导致业务线程hang住，导致服务框架线程池满等问题。MSE Agent支持动态使用异步日志打印能力，将日志打印任务与业务线程分开，提高业务线程吞吐量。小流量预热应用启动后，大量请求进入，导致应用存在许多问题,所以需要微服务的一些能力来解决服务预热问题JVM JIT编译线程占用CPU过高，CPU/load短期内飙高，Dubbo 处理请求性能下降瞬时请求量过大，导致线程阻塞在类加载、缓存等，从而导致 Dubbo 服务线程池满小流量预热，MSE 服务治理通过 OneAgent 无侵入提供了以下几种能力客户端负载均衡通过增强客户端负载均衡能力，对于刚上线的需要预热的节点进行流量权重的调整，做到刚上线的应用按照用户所配置的规则进行小流量预热，用户只需指定预热规则即可按照预期对刚上线的节点进行小流量预热业务方的一台服务端实例使用服务预热后的效果服务预热开启后，待预热的应用将在预热周期内通过小流量实现应用启动过程的预热初始化。下图预热时长为120秒，预热曲线为2次的预热效果图：说明 该测试Demo是定时伸缩模拟应用启动，因此除了预热过程，还包含应用下线的过程。下图预热时长为120秒，预热曲线为5次的预热效果图：如上图所示，相比于2次预热过程，5次预热过程刚启动的这段时间（即17:41:01~17:42:01），QPS一直保持在一个较低值，以满足需要较长时间进行预热的复杂应用的预热需求。服务端分层发布通过修改服务注册的逻辑，增加对应用load等指标的监控，对服务进行分批注册已经回滚注册等逻辑，保证服务注册过程中，流量分服务进入，系统load始终低于阈值，并且需要在指定时长内将服务注册上去。缺点：在应用的服务流量平均，不存在超热点接口的情况下，分层发布可以很好地解决服务预热问题。但是如果应用存在一些超热服务，可能这个服务几乎占所有流量90%以上，那服务端分层发布效果并不会很明显。注意：对于一些存在依赖的服务接口，服务分层发布可能需要业务梳理服务分批发布的顺序打通K8s与微服务生命周期K8S提供两种健康检查机制：livenessProbe，用于探测不健康的Pod，探测失败将会重启Pod。readinessProbe，用于探测一个Pod是否就绪接受流量，探测失败将会在Service路由上摘取该节点。如果不配置 readinessProbe ，默认只检查容器内进程是否启动运行，而对于进程的运行情况很难考量，Mse Agent 通过对外提供 readiness 接口，只有 Spring Bean 初始化完成以及异步资源准备就绪并且开始服务注册时， readiness 才返回 200。将微服务侧的服务暴露与 K8s Service 体系打通，使K8s管控能感知到进程内部的服务就绪时机，从而进行正确地服务上线。我们需要在MSE无损上线页面开启无损滚动发布的配置同时给应用配置K8s的就绪检查接口，如果您的应用在阿里云容器服务ACK上，可以在阿里云容器ACK服务对应应用配置的中健康检查区域，选中就绪检查右侧的开启，配置如下参数，然后单击更新。该应用在下次重启时，该配置即可生效。服务并行订阅与注册通过并行的服务注册与订阅，可以大幅提升应用启动的速度，解决服务启动慢的问题。以并行服务订阅为例：如上图所示，通过 Java Agent 将服务框架 refer 的流程从 SpringBean 的初始化流程中剥离出来并且通过异步线程来实现服务的并行订阅与注册。总结通过不断地观察业务情况，然后进行不断地问题分析思考与解决的尝试，直到开启了服务小流量预热能力后，彻底解决了业务团队应用在上线期间线程池满导致请求有损的问题。发布期间 Exception 总量与发布日期（包含无损上线功能陆续上线的节点）的情况如下图 9月15号发布了服务小流量预热能力后，发布期间相关 Exception 下降至 2。（经业务方确认不是因为发布引起的，可以忽略）上线了无损上线功能后，业务团队的应用中心持续多个月的发布报错问题总算告一段落，但是无损上线功能远不止于此。还解决许多云上客户上线有损的情况，功能的能力与场景也在不断地解决问题中逐渐完善与丰富。MSE 无损上线MSE 服务治理一个特点是通过 Agent 无侵入地支持市面上近五年来Dubbo、Spring Cloud所有版本，所以无损上线这个功能也会是如此，下面会以Dubbo为例子无损上线的功能，当然所有能力我们都是无缝支持 Dubbo、Spring Cloud 的。下面开始系统地介绍一下 MSE 服务治理的无损上线，我们可以先从开源的一个 Dubbo 应用上线的流程开始分析应用初始化，Spring Bean容器初始化收到 ContextRefreshedEvent后，Dubbo 会去拉取 Dubbo应用所需的配置、元数据等exportServices 注册服务开源 Dubbo 上线流程还是非常完善与严谨，但是依旧存在一些场景会导致服务上线存在问题当服务信息注册到注册中心后，在消费者看来该服务就是可以被调用的。然而，此时可能存在一些数据库、缓存资源等一些异步资源尚未加载完毕的场景，这取决于你的系统有没有对应的组件，它们何时加载完毕，也完全取决于你的业务。如果在大流量的场景下，服务在注册到注册中心后，马上有大流量进入，存在一系列问题，导致线程阻塞，对业务流量造成损失比如Redis的JedisPool连接池创建后并不会立即建立连接，会在流量进来后开始建立连接，如果一开始涌进的是大流量，则导致大量线程阻塞在连接池重的连接的建立上FastJson 以及 Jetty/tomcat等低版本中，并未开启类加载器并行类加载能力，导致大量线程阻塞在类加载器加载类上JVM JIT 编译问题引起cpu飙高线程阻塞在业务日志上云原生场景下，微服务与K8s的生命周期未对齐的情况滚动发布，重启的pod还未注册至注册中心，但是readiness检查以及通过。导致第一个pod还未注册至注册中心，最后一个pod以及下线，导致短时间内的客户端NoProvider异常针对如上问题，MSE 服务治理不仅提供了完整的解决方案，还提供了白屏化开箱即用的能力，动态配置实时生效。同时 MSE 服务治理针对无损上下线的场景还提供了完整的可观测能力。无损上线功能可以总结为以下这张图不只是无损上下线无损上下线能力是微服务流量治理中的重要的一环，当然除了无损下线，MSE还提供了全链路灰度、流控降级与容错、数据库治理等一系列的微服务治理能力。服务治理是微服务改造深入到一定阶段之后的必经之路，在这个过程中我们不断有新的问题出现。除了无损上下线，服务治理还有没其他能力？服务治理能力有没一个标准的定义，服务治理能力包含哪些？多语言场景下，有无全链路的最佳实践或者标准？异构微服务如何可以统一治理？当我们在探索服务治理的过程中，我们在对接其他微服务的时候，我们发现治理体系不同造成的困扰是巨大的，打通两套甚者是多套治理体系的成本也是巨大的。为此我们提出了 OpenSergo 项目。OpenSergo 要解决的是不同框架、不同语言在微服务治理上的概念碎片化、无法互通的问题。OpenSergo 社区也在联合各个社区进行进一步的合作，社区来一起讨论与定义统一的服务治理标准。当前社区也在联合 bilibili、字节跳动等企业一起共建标准，也欢迎感兴趣的开发者、社区与企业一起加入到 OpenSergo 服务治理标准共建中。欢迎大家加入 OpenSergo 社区交流群（钉钉群）进行讨论：34826335

演讲嘉宾简介：张瓅玶，花名谷朴。阿里云容器平台集群管理团队负责人，研究员，阿里巴巴集团上云核心决策组成员。2017年加入阿里巴巴。之前在Google的基础设施事业群的集群管理部门工作了5年多，并领导了资源管理和优化团队，负责Borg以及基础存储资源的优化，负责了FlexBorg， Autoscaling等多个产品。加入Google前在加州大学伯克利分校从事智能系统的研究工作。本科和博士毕业于清华大学。以下内容根据演讲视频以及PPT整理而成。观看回放 https://yq.aliyun.com/live/2783本次分享主要围绕以下三个方面：一、核心系统上云演进二、上云挑战及变化三、未来演进一、核心系统上云演进如下图左侧，最初阿里巴巴电商核心系统是不具备容灾能力的。随着核心系统的演进，慢慢具备了同城容灾能力，到今天阿里巴巴核心系统已经具备多单元，异地多活结构，可以实现灵活切流，具备极致高可用和容灾能力。同时在国内多个地域进行了部署，包括华东，华南及华北，而且具备国际化部署能力。第一阶段：自建基础设施在核心系统上云之前，阿里巴巴一般是自建基础设施，到2015年阿里巴巴核心系统已经具备中心同城容灾，多单元异地多活的能力。如果把阿里巴巴核心系统简化，如下图蓝色部分，运营商CDN是整个核心系统的入口，进来后有多地多个区域有多个机房，通过统一接入负载均衡，进入服务注册中心，通过中间件处理消息及事务，进入交易导购的应用，再通过缓存访问数据库。第二阶段：核心系统双11弹性上云从2015年到2018年内，阿里巴巴在双11期间的采取弹性上云策略。双11本身对阿里巴巴的业务系统是一个非常大的挑战，双11期间业务的峰值会达到平常峰值的几十倍。但是以业务资源成本来看，显然无法分配几十倍的业务资源成本支持双11当天的流量，从效率层面也是不现实的。因此在2015-2018年间，通过弹性上云策略将交易导购的应用短期扩容到阿里云ECS上，从而支持大促成本降低的目标。第三阶段：核心系统全面上云在2019年年初，阿里巴巴CTO，行癫提出在2019年将阿里巴巴核心系统全面上云的目标。实际上，在2019年双11前，阿里巴巴核心系统已经全面上云了。由于在核心系统的架构上具备同城容灾和多单元化部署的能力，从而给核心系统上云带来了极大的便利。以中心为例，首先在云上申请神龙ECS资源，通过中心的同城容灾，将中心一个机房的应用及统一接入层实现上云，在过程中通过服务注册中心，消息和中间件统一机房的设置，实现迁移的过程中业务无中断。在云上部署并完成测试后，可以将流量迁移到云上机房。因为是同城容灾的架构，故可以将云下机房的流量的切断，切到云上机房。同时可以对中心其它机房进行相同的操作，完成流量迁移的过程。同时单元化的部分也经过了类似的过程，整个实施过程投入了大半年的时间。核心系统全面上云是一次平台重构（replatforming），将基础平台都迁移到云上，从原来基于自建的策略改为现在所有应用，数据库等都基于云的核心系统。为什么阿里要核心系统上云？随着公有云技术的演进，公有云上很多产品的能力相比于传统基于自建的系统的能力有了显著的提升，比如云上神龙服务器，云上核心数据库，既吸收了阿里巴巴内部技术的创新，同时在对外服务客户的过程中，也在不断积累独特的创新能力。云上产品可以更好的支持阿里巴巴的业务。反过来，阿里巴巴内部的系统也具备一些独特的场景，如平时比较复杂的电商场景，可以对云上产品有更好的打磨效果。阿里系统通过核心系统的上云，不断的打磨云产品，从而使得云产品能力得到不断的提升。其次，通过核心系统的上云，可以让性能，成本及稳定性收益形成良性闭环。二、上云挑战和变化上云挑战众所周知，阿里巴巴双11是对业务来说是一个独一无二的挑战。其中包括对容器规模的挑战，在大促期间，集群规模超过百万，单集群规模达到10000以上。2019年双11的数据库峰值能力达到54.5万笔订单每秒，数据库TPS达到8700万，实时计算Blink处理峰值达到25亿消息每秒，消息系统峰值达到1.5亿消息每秒。这些数值是对业务的极致性能和极致稳定性的要求，过去是依靠阿里巴巴集团自由技术体系多年的打磨，那么如果上云，云产品是否能够支撑这样的极致要求同时提供红利？计算存储在上云之前，阿里巴巴计算是依靠传统的物理机+容器的架构。传统的架构面临几种架构缺陷，一方面是面临资源争抢的挑战，且隔离性较弱。同时会占用宿主机的资源，对系统算力造成损失，成本变高。另外，所需的IO引擎通过纯软件的方式实现，会遇到较大的性能瓶颈，尤其在双11期间，IO引起的性能问题一直是较大的挑战。其次，由于应用网络存储和设备共享导致容器相互影响，性能抖动等问题也是目前的主要挑战。在2019年完成迁云之后，计算层使用神龙+容器服务作为最佳计算基础设施。神龙的特点是通过对网络和存储硬件基础的虚拟化，将原来宿主机的开销卸载到单独的子系统上，虚拟机的卸载使得物理机的资源都为业务负载所用。同时让物理机上的容器相互之间不会因为共享IO通道产生干扰，对长尾延迟及资源的生长情况有显著的改善。在2019年双11期间，在高负载压力下的某电商应用QPS提升了30%，同时资源的利用率也有显著的提升，CPU利用率提升了80%，降低了延迟时长。下图对比了物理机部署和神龙部署的延迟情况，可以发现当业务负载逐渐提升时，神龙延迟的下降是非常明显的，而传统的物理机由于资源的争抢会导致延迟时长快速上升。云化存储云化存储也给阿里巴巴核心系统上云的演进带来了积极的影响。一方面，云上的高密度，弹性能力，长尾延迟的优化，对于应用的性能和稳定性带来了大幅度的提升。另一方面，在云上实现了存储计算的分离，不需要再去管理，规划和存储，从而给整体应用架构带来了大幅度的简化。下图左侧展示了单体应用的架构，包含应用、本地文件系统、本地磁盘。迁移到云上后采用云化的存储实现存储计算分离，架构变成了类似如下图右侧，业务只需关注应用，通过存储虚拟化访问云存储。在存储计算分离后，阿里巴巴硬件采购更灵活，只需要做计算量的采购，不需要考虑磁盘容量问题。在应用层面，所关心的维度也变少了，目前只需要关心CPU和内存水位，提高了资源分配成功率和资源利用率。最后，存储的分离使得应用的迁移效率更高，提升了可移性，无须迁移本地数据。网络性能在上云之前，阿里巴巴的架构是企业内部网的架构。由于上云的迁移是持续的过程，所以需要构建高速的混合云网络。云上云下对传流量较大，因此在云上采用了云专线的方式实现云上云下的高速互通，同时具备城域网架构支持良好的可扩展性。但同时也面临跨安全域full-mesh互通的问题，阿里通过对整个安全域和安全组的设置，进行了很好的解决。整个过程中，云上的xGW网关和软硬件结合的交换机能力也使得上云之后的网络性能有了大幅度的提升。资源管理和规划在上云之后，以双11和618大促为例，在3年前，阿里巴巴需要为大促峰值做单独的资源准备，而且这些资源很难立刻被完全释放掉，一般消化时长需要按年进行统计。，供应链及企业的弹性来说是一个较大的痛点。阿里巴巴也做了很多容器化，统一调度，混部等方案，这些本质上属于云化的过程。当真正上云后，云会提供一个产品化的解决方案。当资源池规模呈指数级别增长时，资源可以即买即用，用户不用关注架构优化问题，也不需要关心供应链问题，弹性资源池能力有了大幅度提升。上云之前的资源规划如下图，业务实际需求是一个曲线，当有大促活动时，需求会极速增长。但交付时是按照粗颗粒度进行物理机的采购，而采购往往是批量采购，并且需要提前采购物理机。下图绿色线条下的面积是实际机器库存。上云之后即使还是按照绿色线条做容量规划，并且上交阿里云，但实际的规划可以很好的贴近业务需求，少批量多次的弹性采购，从而大幅度减少冗余资源。下图右侧绿色和橙色间的面积是优化节约的资源。混部方案变化下图展示了在上云之前在阿里巴巴集团内部，将大数据和电商应用通过混合部署，从而节省成本的方案。但受限于机房资源的规划，会产生很多空闲资源或不具备条件的资源。上云之后，可以使用云提供的产品化方案，充分使用资源，通过相对简单的云化技术方案，达到业务无降级的效果。三、未来演进解决问题上云已成为趋势，但核心系统上云对大企业来说还是会面临很多挑战。阿里巴巴在2019年完成了核心系统的上云，相信对其它企业也可以慢慢克服这些挑战，并且完成上云。但核心系统上云只是下一个开始，并不是终态。阿里巴巴技术团队下一阶段将主要解决以下问题，首先是持续提升研发运维效率，让业务更快迭代，这是每一个公司技术团队最核心的使命。同时需要不断优化，从而减低资源成本。最后，保证安全生产和稳定性。新架构演进如果将上云之前的阶段分为两大阶段，第一个阶段是弹性使用云资源，在2018-2019年间，阿里巴巴在双11期间使用了云资源降低成本。第二阶段是2019年开始核心系统上云，真正以云为平台。下一阶段将是云原生化，那么什么是云原生？云原生从价值的角度来说，云原生化是企业应用架构的一次升级，云原生是构建和运行可弹性扩展、容错性好、易于管理的系统的最佳实践。一方面，云原生化通过容器和资源的编排，带来效率和资源利用率的提升。另一方面，通过微服务化分布式系统的可弹性，带来整个应用扩展与可靠性的提升。此外，云原生化的开放标准带来了无供应商锁定的特点。同时持续交付带来了创新迭代速度的提升。这些价值是阿里巴巴非常看重的，同时也希望可以获取到这些红利。云原生上云之痛从上云视角看，云原生（Cloud native）化是最大化使用云的能力，以开放标准重构阿里巴巴技术体系和架构，让企业聚焦于业务的实践。但同时因为云原生上云是对整体体系的挑战，因此会面临以下几种痛点。首先，传统面向富容器、定制化的运维和监控体系迁移到标准化体系，应用架构向微服务化转变，此类运维体系升级对企业来说也是不小的挑战。随着容器化的普遍深入，给企业提供标准化的运维体系，可以极大的降低云原生上云成本。其次，在更深入使用云产品过程中，应用所依赖的中间件和后端服务也要迁移，同时发生了应用架构的变化，此时云上所提供的很多标准的基础设施可以极大的降低成本，技术人员可以更多的聚焦在自身业务技术及能力，无需在基础设施和产品上投入大量人力。第三，在升级过程中会不可避免的面临组织挑战，如果之前企业有in-house自建和维护团队，是否可让他们参与业务系统的开发，同时可以实现人员效率的提升。应用与基础设施全面解耦将云原生之前的一个典型的应用架构拆分后，如下图，带有富容器模式的特点，与基础设施有深度的耦合，包括监控Agent、日志Agent、系统进程、命令通道、中间件、本地缓存，最上面才是业务进程。此类架构会使得应用与基础设施间存在强耦合，从而使得配置管理复杂，发布升级慢，可迁移性不高。在上云时，架构本身的运维及研发演进效率也会受到影响。因此针对这种高耦合性，需要全面的对应用和基础设施进行解耦。即通过应用架构的演进，将业务应用与运维，可观测性，中间件等逐渐分离，也称为轻量化容器和不可变基础设施的分离。同时，过去的复杂度来自流量的复杂度和网络的管理和配置，通过服务网格化的演进，可以很好的将业务进程与基础设施的网络的进程解耦开来。通过这些演进可以使得应用更多的关注自身的逻辑和主容器，让流量、运维和可观测性变成云基础设施的一部分，进而可以使用标准的云产品进行替代。无服务器化如果进一步可以让业务的runtime更无服务器化，则业务会变得更轻量，效率也会进一步提升。上云的深入本质上是走向无服务器化，无需管理底层服务器资源，实现从0到无限的资源弹性，按需计费。以上是无服务器化的基础设施可以提供的价值，对应用与运维和研发的效率都有很大的帮助。云原生上云的价值红利云原生上云对企业的价值红利，一方面是通过云上的标准产品的标准化、快速演进给企业带来技术红利。云厂商和社区都在大量的投入云原生技术，如阿里巴巴，谷歌，微软都已投入在社区开发标准的云原生技术的建设中，这会给云原生软件生态带来红利，如容器、微服务、K8s、服务网格都是近几年得到了快速的成长。云原生技术领域将成为云厂商竞争和投入的主战场。云传统的优势包括规模、稳定性，成本等，这些已经逐渐发挥到极致。通过容器、微服务云原生技术开始向上接触到了应用负载的感知，持续的创新给研发和运维带来效率上的优势，从而不断的获得客户的认可。在云厂商将云原生技术作为竞争和投入的主战场可以使得云产品逐渐的成熟，为客户带来更大的价值。随着云原生的技术的发展，应用部署逐渐走向云边端一体化，这对企业管理跨环境云边端应用带来了极大的便利。云技术体系的演进，云原生技术和产品的发展，云产商对云原生的投入，使得阿里巴巴相信云原生上云是阿里巴巴下一步主要的方向。阿里巴巴相信核心系统通过上云的深化，可以获得更大的技术红利，同时获得研发和运维效率的提升。在稳定性和成本优化的基础上，相信云原生也是其它企业未来技术演进道路上值得考虑的一个方向。

一、介绍1、微服务开发的问题 微服务架构下我们在开发中遇到的常见的问题有以下4个：多语言问题：有多种编程语言，node.js, JAVA, GoLang…微服务需要为每种语言都维护一种中间件SDK升级推动难：SDK升级需要推动业务应用进行代码修改和发布，对业务有打扰，业务压力下推动成本高迭代速度慢：由于多语言多版本的存在，需要花费大量精力去维护历史版本，降低了迭代速度，升级速度慢 （在数据面选型上也考虑研发效能的问题）多版本问题：每种语言的SDK都面临版本升级，同时存在大量不同的版本互相访问，兼容性和测试维护成本巨大为了解决这些问题，服务网格的Sidecar + APP 模式是一个很好的方案2、服务网格Service Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。服务网格的概念被提出也有很多年了，服务网格的也出现了很多不同类型的实现，比如Istio、Linkerd，Open Service Mesh等等，还有出现类似ebpf + envoy，proxylessMesh等等其他方式的服务网格实现，其实都是在想如何解决当下生产、开发中的问题，我们熟知的关注度最多还是Istio，架构如下：通过Sidecar和业务应用分离，控制面Istiod实现对整个流量的管控，基于Istio + Envoy的能力实现了微服务的连接、安全、控制和可观测，服务网格在微服务架构下体现了与应用解耦的平台级服务治理能力，推出来统一的多协议多语言的微服务治理，同时保持了基础架构与应用解耦，降低升级和运维的成本，而且实现了微服务间的安全可靠通信，让不同类型的微服务的通信具备可观测。二、阿里云专有云服务网格能力服务网格的优势被大家广泛认可，直到今天已经有很多的用户将服务网格使用在自己的生产业务系统中，但是对于很多的常见的用户而言使用和运维这样的一套系统还是过于复杂，在通常的使用中，可能我们只需要做一次灰度发布，这时候就涉及不同规则的配置，非常容易出错，如何定义好应用的VirtualService、DestinationRule等规则对于大部分使用者而言都需要很高的学习成本，为了减少使用的成本和运维难度，阿里云专有云服务网格通过高度的产品化能力将服务网格的能力推出，只需要按照常见的思路去操作控制台，即可轻松的完成比如灰度发布、标签路由、鉴权、全链路等能力。下面是一张阿里云专有云服务网格的能力大图，覆盖了协议、环境、服务治理、可观测、安全生产几个方面：接下来来介绍下我们的产品能力：1、服务治理1.1、流量管理流量管理的能力很多，包含了负载均衡、熔断、限流、超时、重试、流量镜像、连接池管理、故障注入、同AZ路由、服务Mock。限流的能力提供了单机的限流、基于header的限流、Path的限流故障注入中除了开源社区的服务级别的故障外，还提供了针对服务单个Pod的故障注入，这样可以进行单个Pod的测试。服务Mock的能力可以为开发人员Mock指定接口的返回，在接口还没有开发完成的时候，提高开发测试的效率，服务Mock的配置中可以选择请求的路径、端口号、方法、状态码、Header、返回Json数据。1.2、标签路由通过标签路由可以选择好基线的版本，然后选择对应的路由版本，配置路由策略，比如基于权重的策略、基于内容的策略，通过简单的配置轻松完成路由规则的配置。1.3、服务注册服务注册其实顾名思义就是将微服务注册到注册中心，这个能力主要是为了帮助一些非Java类型的服务实现跟已有Java类型服务的通信，比如Spring Cloud 服务需要与非Java互通，为了方便代码编写，Spring Cloud 服务需要像调用其他Spring Cloud服务一样去调用非Java服务，因此就需要非Java的服务注册到对应的注册中心，这里我们支持了非Java服务注册到Nacos、Eureka注册中心。1.4、运行监控展示服务的运行监控数据，比如平均处理请求的次数、请求的成功率1.5、灰度发布可以通过发布版本的方式发布一个灰度版本的镜像，填写对应的版本号、镜像，可以配置权重、内容路由规则，可以使用回滚、灰度成功能力。1.6、零信任安全可以配置双向身份认证、请求的JWT认证，还可以配置对应的授权策略。2、全链路路由全链路路由可以实现在整条调用链按照指定规则路由，比如在测试某个服务是否符合预期，但是测试服务需要依赖其他服务，这时候可以通过全链路的能力，拉出一个开发环境的泳道，将指定tag标记的流量打到测试服务中，而其他请求还在基线环境中，这时候如果还有其他服务需要测试，也可以加入到这个泳道中一起测试，全链路路由的好处就是可以任意路由到服务链路中间服务，在基线环境外研发/测试人员可以轻松部署一套独立环境，提升研发测试效率，降低运维成本。2.1、创建泳道创建一个属于对应服务网格的泳道，即为不同的环境（创建泳道前先确定号基线版本环境）。2.2、发布服务/导入服务创建好泳道后可以发布一个服务到泳道中，也可以导入部署的服务选择入口的应用，配置规则（什么样的流量特征的请求可以进入泳道中）3、入口网关通过服务网格的Istio Ingress Gateway的能力可以将服务网格内服务暴露出去，协议上我们支持HTTP、HTTPS、GRPC，除了暴露之外，我们还支持配置路由规则，这样可以对入口服务的流量进行管理。4、外部服务通过外部服务纳管将网格外的服务纳管进来管理，可以配置服务的协议、地址、EndPoint，还可以配置服务不同EndPoint的标签5、服务拓扑结合Prometheus + Kiali，可以展示整个调用链路的拓扑结构，其中包含了调用的服务、版本等信息6、网格管理6.1、集群管理可以通过简单的接入集群的能力，将已有的k8s集群加入进来，加入进来后，可以通过网格管理中创建网格的能力，在对应的集群中部署服务网格，创建网格时候可以配置网关、控制面Istiod的高可用能力、配置集群中服务的Sidecar资源（也可以单独配置）、是否打开AccessLog日志等能力。6.2、网格配置管理创建好服务网格后需要对网格进行管理、配置，在高级选项中可以看到常见的配置，比如网关高可用、控制面高可用、网关的资源、控制面资源、服务访问限制、可观测等。除了这些外，还提供了服务网格对接注册中心的能力，这里我们支持了常见的Nacos、Eureka、Zookeeper、Consul注册中心对接到服务网格中。6.3、多集群管理单集群的可以满足大部分用户的要求，但是为了容灾，多集群的管理、互通也非常重要，服务网格的多集群能力在社区版本中也支持，但是配置复杂，我们的产品中提供了一键管理多集群的能力，通过多集群配置-纳管集群的能力，轻松的实现多个集群之间应用的互通、治理。三、部署和输出我们支持通过阿里云混合云企业版输出、CNStack 输出，同时我们也支持独立部署输出，只需要一个k8s集群，可以快速轻松拉起专有云服务网格的能力，体验产品化的服务网格能力。

　　第一代Service Mesh　　第二代微服务模式看似完美，但开发人员很快又发现，它也存在一些本质问题：　　其一，虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事;　　其二，开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到;　　其三，框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级;　　因此以Linkerd，Envoy，NginxMesh为代表的代理模式(边车模式)应运而生，这就是第一代Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的三个问题也迎刃而解。

　　目前业界跟微服务相关的开发平台和框架更是不胜枚举：Spring Cloud， Service Fabric，Linkerd，Envoy，Istio ...　　这些纷繁的产品和Sevice Mesh有什么样的关联?哪些属于Service Mesh的范畴?　　为了理清这些繁复的产品和概念，我们先来了解下微服务和Service Mesh技术的历史发展脉络。　　了解清楚了技术的主要脉络，就能清晰的知道上述的各个平台、框架属于技术脉络中的哪个结点，其间的关系也就一目了然。　　Phil Calçado的文章《Pattern: Service Mesh》，详细的介绍了从开发者视角来看，服务开发模式和Service Mesh技术的演化过程，个人认为是非常经典的学习Service Mesh的资料。这里借用文章的脉络，结合自己的理解并予以简化，试图说清楚ServiceMesh的概念和这项技术诞生的历史必然性。你可以把本文当做原文的一个中译版本来阅读。　　时代0：开发人员想象中，不同服务间通信的方式，抽象表示如下：　　时代1：原始通信时代　　然而现实远比想象的复杂，在实际情况中，通信需要底层能够传输字节码和电子信号的物理层来完成，在TCP协议出现之前，服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还夹杂着对网络传输问题的处理逻辑。　　时代2：TCP时代　　为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑，TCP协议出现了，它解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操作系统网络层的一部分。　　时代3：第一代微服务　　在TCP出现之后，机器之间的网络通信不再是一个难题，以GFS/BigTable/MapReduce为代表的分布式系统得以蓬勃发展。这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等，于是服务根据业务需求来实现一部分所需的通信语义。

　　Service Mesh 作为下一代微服务技术的代名词，初出茅庐却深得人心一鸣惊人，大有一统微服务时代的趋势。　　那么到底什么是 Service Mesh?　　一言以蔽之：Service Mesh 是微服务时代的 TCP/IP 协议。　　有了这样一个感性的初步认知，我们再来看到底什么是Service Mesh。　　提到Service Mesh，就不得不提微服务。根据维基百科的定义：　　微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。　　目前业界跟微服务相关的开发平台和框架更是不胜枚举：Spring Cloud， Service Fabric，Linkerd，Envoy，Istio ...

作者 | 陈泽涛（硬之城产品总监）& 洛浩（阿里云云原生高级架构师）硬之城成立于 2015 年，是一家以电子元器件 BOM 整体供应为核心，为中小科技型硬件企业提供 BOM 标准化、BOM 报价、BOM 采购、BOM 交付和 SMT 一站式 PCBA 服务的电子产业数字供应链与智能制造平台。作为入选阿里云首期云原生加速器的企业，硬之城此前也获得了阿里云首批产品生态集成认证，通过云原生加速器项目携手阿里云共建更加丰富的云原生产业生态圈，加速云原生落地。背景电子产业互联网的需求是离散和复杂多变的，相比传统的代码开发，每一个市场需求的研发都需要耗费不少的研发资源投入到对应的需求开发中。这其中不仅有代码开发的工作，而且前期与工程师间的沟通工作也占用了不少资源。这不仅让每个需求都会消耗不少的研发成本，而且市场的需求也需要等待研发完成才能响应。这也是为什么硬之城选择做低代码平台的原因。我们在实际的业务中，会频繁的收到来自市场的需求，这些需求还存在一部分不确定性和尝试性的需求。为此一直让我们的研发资源相当紧张。低代码平台的打造，不仅让没有编程基础的业务可以快速上手，让各业务部门都可以搭建自己的管理应用，大大缓解了研发资源紧张的问题。在我们实际的使用过程中，发现低代码平台不仅可以覆盖许多简单的需求研发，而且许多常规的、复杂的需求也可以通过低代码平台完成。特别在不确定性和尝试性的需求，由于此类需求本身存在不稳定性，需求变更的情况非常普遍。这时由于低代码的迭代成本和门槛低，业务可以直接在后台修改应用，以达到快速的响应市场目标。目前我们低代码平台使用 Java 和 Nodejs 开发，后端采用 SpringBoot，前端采用 Vue，基于 ECS 进行部署时，采用 Shell 脚本发布，并基于 Nginx 负载到多台主机。但是我们经常会碰到服务器资源占用不平衡，运维成本高，操作权限分配繁琐等问题，这给我们整个团队的协作造成了困扰，为此我们一直在寻找对应的解决方案。一直到我们发现可以实现全托管、免运维、高弹性的 SAE 平台。SAE 支持开源微服务、开源定时任务框架、Web 应用的全托管。为此我们进行了架构搭建，发现 SAE 可以合理分配应用和服务器之间的资源，以及应用动态伸缩灵活性。这有效的降低了服务器运维门槛，避免风险操作，简化了我们团队成员对应用蓝绿发布的操作流程，提升了发布安全性和可靠性。通过一段时间的使用，我们目前可以通过云效流水线发布 SAE 应用，镜像构建存储都缓存到阿里云镜像库，每位该项目的开发人员都能通过流水线发布应用，并且基于阿里云 RAM 系统可以很好的控制权限，发布效率大大提升，每一个 SAE 应都对应有独立的节点，不需要考虑应用是要选取发布到哪一台主机，只需要做好 SLB 负载均衡，实际资源用多少付费多少，也不需要操心服务器的各种机器维护问题，明显提升了运维工作的效率。对应用本身来说，就是人效的提升，更加方便简洁的步骤就能完成一个应用的部署周期。对于运维管理上来说，就是更加轻便，少了很多诡异的操心事。对于整个微服务架构来说就是脉络更加清晰，可扩展性更强，只需要点一下即可扩展更多更强的负载能力。公司做成本预算的时候也能更加可控，不需要一堆服务器和 IP。硬之城低码平台未来规划及愿景未来我们期望业务与技术能并行。适合业务自行管理的需求，业务自身可以通过低代码就可以快速的完成他自己的需求上线，并自行维护。对于非常复杂及存在技术门槛的需求，此时技术人员才介入，让技术人员更专注的解决高价值、高技术的问题。这不仅让业务可以快速响应市场需求，也让技术人员有更多的精力去解决企业的技术问题。最终让企业的业务人员和技术人员都流动起来，专注起来，以此来让企业更加有活力。SAE 针对 SaaS 场景的方案及优势通过硬之城的实践，我们也能感受到 SAE 对开发和运维效率的极大提升，如下图所示，这其实是因为 SAE 结合了容器、Serverless、微服务的优点，打造一站式应用开发部署平台。对下屏蔽了 K8s 等资源维护的复杂性，对上提供全应用生命周期管理、微服务治理、APM、弹性管理等能力，可以让用户更简单的完成容器化、应用迁移、业务上云。同时对于已经实现了微服务化、或者仍然处于单体架构的存量应用，SAE 也可以支持 “0” 代码改造迁移。如下图，假定业务是基于 ECS 部署的，如果想提升业务的弹性能力以更好的应对流量波动，或者就是单纯的想简化资源的管理和运维等繁琐的事情，那么 SAE 就可以直接把 ECS 替换掉，也就是把部署在 ECS 上的业务代码在 SAE 平台上重新部署即可，前端安全、后端数据库等资源的部署和使用仍然保持不变。这里需要提醒下，如果是基于 ECS 自建的数据库、消息中间件等带强状态的服务，是不适合迁移到 SAE 上的，毕竟一旦发生弹性伸缩，就会造成 “状态数据” 的缺失，如果不是对价格非常敏感，建议这部分服务可以迁移到云上的 PaaS 产以取得更好的稳定性。基于以上两点，我们就可以再进一步的扩展，针对大部分 SaaS 企业客户，我们发现有两类业务诉求：一类是采用订阅制的 SaaS 企业，打造自身的服务平台，对外提供像订票、餐饮服务、机酒、出行、ERP、HRP 等服务。这类企业核心关注的是垂直业务领域的竞争力和敏捷迭代，以保证自身能够快速响应市场。同时这类业务对弹性也存在着较大的诉求，那么基于 SAE 构建弹性微服务能力、或者弹性容器就非常的契合，既可以让用户聚焦业务开发，同时平台提供资源管理、弹性、应用管理等一体化的能力，极大的简化了运维成本，还能通过弹性来提升资源利用率，达到节省资源成本的目的。SAE 还可以和 Jenkins 或者云效联动构建流水线，来提升整体的开发部署效率。还有一类 SaaS 企业会承接很多独立部署的需求，把自身构建的业务平台在最终客户的阿里云账号或者 IDC 里进行单独交付。针对阿里云上部署的服务，就会面临着开资源、部署、后期运维等一系列流程，尤其是最终客户的技术能力参差不齐，那么如何能快速完成业务部署、并简化后期的排障和维护工作就显得尤为重要。在这里，SAE 提供了基于 terraform 的一键部署方式，可以把业务代码+SAE 资源、VPC 网络、SLB、数据库等构成业务系统的全部产品资源，分钟级部署并拉起，具备极强的可复制性。如下图所示，再加上 SAE 自带的 APM 监控能力和弹性免运维的特性，对于后续交付最终客户后，也能极大降低维护成本。Serverless 已经成为云计算的下个十年，期望阿里云的 Serverless 能力，能够给越来越多的用户带来便捷，简化用云的成本，把复杂留给自己，简单留给用户。深圳前海硬之城信息技术有限公司（简称硬之城）成立于 2015 年 8 月，总部位于中国深圳。​硬之城致力于解决电子产业采购难、制造难、效率低、产业链协同弱等痛点，加快硬件创新产品的制造周期，提高产业链的生产和流通效率。硬之城基于 SAE 低代码跑出产业互联网应用创新加速度。实现硬件从 “方案设计”、“元器件交付” 到 “生产制造” 等电子产业链重要环节数字化和智能化转型升级。​硬之城紧紧围绕客户项目交付，为企业提供覆盖全生命周期的一站式数字化供应链服务，将客户从复杂、繁琐的供应流程中释放出来，集中精力专注于自身产品和技术，助力客户快速发展。与传统供应链相比，硬之城打造的数字化供应链管理体系，将中小批量硬件生产制造时间由 2-3 个月缩短为 2-3 周，实现硬件制造效率极大提升，有效增强中小型硬件企业的竞争力。戳此处了解更多 SAE Job 的功能优势，和众多开源任务框架“低门槛”迁移的方案！