点击上方“”可以订阅哦
继上周发布 之后，我们再次为没能亲临奥斯汀 现场的童鞋们梳理本届峰会SDN网络主题的重要技术讲座。有云SDN网络部PTL王为在奥斯汀峰会期间共观看了20余场技术讲座，综合之后再上观看的回放，对36个进行了介绍和评论。
这些网络技术讲座的观影指南涉及架构、功能与工具、开发与其他四大领域。我们将分主题系列发布，希望帮助国内的开发者、架构师和用户更好地了解在SDN网络领域的最新发展。本文所介绍的相关讲座在 均有完整视频（详见：，在 上搜索对应名称即可）。
架构篇观影目录
▼1. OVN , , and of
▼2. and The and
▼3. – with for a –
▼4. – Done the SDN Way
▼5. on Top of a L3 BGP-EVPN
▼'s
1. OVN , , and of
评分：★★★★
简介：开头科普了一下 OVN 的架构，一些做的不错的地方，然后着重介绍了这个 中社区对 的进展和测试，以及其他一些目标。对 OVN 感兴趣的同学应该看一看。
评论：标题虽然叫，但遗憾的是实践的内容并不多，提到了社区做的 测试，主要是利用在20 台物理机上做 2000个的控制平面模拟，IBM在实际物理环境中部署过90个的，下一步要测试 300 台和 700 台的规模。
关于最近的进展，上有一定提升，例如 -nb 和 -sb 分拆到两个进程等，但遗憾的是比较受人关注的 的多进程还在开发中，原生 NAT、摆脱 MQ 等一些关键 也还没有做完。部署上已经支持了 ，同时社区对 也比较重视，这方面做的也不错。下一步的目标主要还是 的 HA（关键 ）、L3 和 NAT 的支持（关键 ）、 的 DHCP、 等等，还有一段路要走啊。
OVN 刚推出很多人看好，原因最主要是强大的社区，其次刚开始给出的设计文档也不错，遗憾的是刚拿出来的版本距离长期设计目标就差的很远（ 的 HA 问题，甚至目前还是单进程的！大量的非分布式实现等等），所以就让很多人忧虑 OVN 是不是太晚了。
一年多过去了，OVN 社区确实做出了很多努力，但遗憾的是前有 ，后有 各种竞争，而且前者发展时间长、已有部署案例，后者在 HA、各种功能（SFC、 等）也有所擅长，而且两者对如何解决数据库/资源同步问题都提出了自己的方案（ 、 sync）等，而OVN社区目前还没有考虑过这个问题，只能说留给OVN的时间已经不多了啊。
2. and The and
评分：★★★★☆
简介：开头科普了一下 的架构，然后介绍了在 OS M 版和 ODL 版上的进展，特别是 V2 版 的情况，值得一看。
评论：V2 是一个关键性但复杂的事情，主要是增强了 HA 和 ，这也得益于 的不断测试。其中的关键问题之一是数据库的不同步。做过类似 SDN 与 对接的开发者都知道，因为事涉两个系统，两个数据库，所以保持数据一致性是一个很麻烦但有很重要的问题，一旦处理不好，轻则状态不一致，重则大量脏数据充斥两个系统还无法轻易删除，最终无法维护。ODL 选择了一个相对简单一些的方案，就是将一个 Sync 操作拆开，拆一部分为独立的循环，这个思路可能是和以前的 学的？
我们可以看到 API 返回过程实际是没变的，仍然是直接写数据库然后就返回，但此时状态时 的，由另一个独立线程周期去取 的数据，然后交给 ODL，这样来保证 API 操作的即时性和状态的一致性。
轻量测试框架看起来对用户不会有很大的影响，但是对开发真会方便很多，跑和 的集成测试不需要专门跑 ODL 了，简化很多。支持了基于 Port 的 OVS DPDK 集成（这样你可以混布 DPDK 和 非 DPDK 了！），100% 通过 测试。在新版的 ODL 上，HA、稳定性、各种 也增强很多，可以认为 ODL 和 集成已经很靠谱了。
在下一个版本中，一方面是 v2 的继续增强，一方面是 SFC、FD.io、、L2GW 等这些的增强。按照 FD.io 的文档，FD.io 社区的计划也是通过 ODL 与 集成网络构架工程师，按照目前的资料 FD.io 的性能特别是多流性能上就超出 OVS DPDK 一大截，值得期待。SFC 有其他 做介绍，这里就不多说了。最后做一点科普， 可以作为纯软的 SDN 后端，具体的模块是 ，也是以 来控制 OVS 完成网络功能，目前功能的完善程度还是比较高的。
3. – with for a –
评分：★★★
简介：这是一个在的短片演讲，主要介绍了ODL本身和其与集成的好处，以及一些客户案例。
评论：对ODL不了解的同学可以看一看，看过 and The and 的同学就不用看了。
4. – Done the SDN Way
评分：★★★★★
简介：开头科普了的架构和意义，然后介绍了最新的进展，其中重点是 DB （你将可以愉快的使用 ETCD、、 等作为分布式的数据库后端）、 消息后端（你可以愉快的使用 0MQ）、分布式的 DNAT、DHCP 和 OVS 实现的安全组均已完成！
评论：在2015年的温哥华 会后总结上，笔者就向国内同僚介绍过 这个生机勃勃架构的项目，主要 中 Gal 和 Eran 都是很有创造力的人网络构架工程师，云网络工程师必看丨6大最新OpenStack网络架构，最近随着国内的马力的加入让这个“小社区”更加充满活力，从他们的 介绍中也能看出里其发展之强。演讲着重介绍了关于数据库一致性的问题解决，和 ODL 重点讨论的那个事情是一样的，区别是二者的方法， 目前采用的是基于锁实现，类似于两步提交，但计划修改成基于版本的对象控制，这个计划其实和 ODL 的实现也是有类似的，但是这里不用状态这个字段，而是用版本，确实看起来更优雅但实现难度还是比较高的。
与 SDN 集成的两大痛点，一个消息问题，一个数据库问题，不同的社区给出了不同的解决方案（弃用 MQ 还是采用分布式 MQ？基于 CAS 的比较还是基于状态的异步处理？），很让人拭目以待。此外 还公布了他们在 上的路线图，随着 0MQ 的引入，他们把理论的 已经提高到 4000 节点，但这还是不是终点，目前的目标是 台节点！
在更新速度上、架构上（他们在架构上在不断进化）都绝对不输目前 几个其他 SDN 方案，唯一遗憾的是社区和声音都小了些，希望未来能有更多的慧眼识珠之人参与进来。
5. on Top of a L3 BGP-EVPN
评分：★★★★
简介：这是一个 出品的其网络结构设计 Case ，主要技术是 EVPN，对大型的 网络设计（ 网络设计）还是很有价值的，演讲附有珍贵的实际性能数据。
云原生架构是什么
回顾过去十年，数字化转型驱动着技术创新和商业元素的不断融合和重构，可以说，现在已经不是由商业模式决定采用何种技术架构，而是由技术架构决定企业的商业模式。所以无论是行业巨头还是中小微企业都面临着数字化转型带来的未知机遇和挑战。机遇是商业模式的创新，挑战来自对整体技术架构的变革。
新一代的技术架构是什么？如何变革？是很多互联网企业面临的问题。而云原生架构则是这个问题最好的答案，因为云原生架构对云计算服务方式与互联网架构进行整体性升级，深刻改变着整个商业世界的 IT 根基。
虽然云原生的概念由来已久，很多人并不理解什么是云原生。从技术的角度来讲，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。简单的说，就是帮助企业的业务功能迭代更快、系统能承受住各种量级的流量冲击的同时，构建系统的成本更低。
传统架构与云原生架构的区别
上图展示了在代码中通常包括的三部分内容，即业务代码、第三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码。“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库。“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。
这三部分中只有业务代码是对业务真正带来价值的，另外两个部分都只算附属物，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂，对开发人员的技能要求也越来越高。云原生架构相比较传统架构前进了一大步，即从业务代码中剥离了大量非功能性特性到 IaaS 和 PaaS 中，从而减少业务代码开发人员的技术关注范围，通过云服务的专业性提升应用的非功能性能力。
这便是云原生架构的核心思路。
为什么需要云原生架构
解释完什么是云原生架构后，大家可能会有进一步的思考，即当今互联网企业为什么需要云原生架构。分析下 SaaS 的市场规模可以发现，2019 年 SaaS 市场规模为 360 亿元，2020 年仍保持可观上涨趋势，2022 年 SaaS 市场规模预计破千亿。
纵观中国企业级 SaaS 行业发展历程，大体分为四个阶段：2015 年之前，中国市场和绝大多数中国企业对“什么是 SaaS”缺乏基本认知，基于私有部署的传统软件形式仍为主流，企业级 SaaS 市场方兴未艾。到了 2015 年，随着云计算技术的进一步成熟，中国企业级 SaaS 行业进入快速成长阶段，这个慢赛道逐渐为公众所知。
时至今日，在疫情、经济、社会环境的大背景下。互联网企业开始寻求新的商业模式，一些抓住机会的 SaaS 企业实现了快速响应，结果是其业务呈现成倍增长，比如：
所以，在“如何活下去”成为热门议题的背景下，快速响应能力成为企业之间的核心竞争优势，SaaS 企业需要及时满足市场的新需求。而这正是前几年中国 SaaS 企业为了快速占领市场、盲目跟风、一味借鉴国外产品所产生的天生缺陷。为弥补这些缺陷，SaaS 厂商需要根据市场的需求快速调整产品服务方向，业务功能要多元化，业务体系需要新的枝杈，在技术上也有更大的挑战。
除了市场带来的压力，SaaS 企业自身也有诸多痛点：
SaaS 企业解决以上的外忧内患的核心就是专注在业务。要做好一款 SaaS 产品，对于业务渠道、竞争格局、用户体验等诸多方面都有更加严苛的要求，甚至从市场运营、产品经理到研发、运维都要专注在业务，所有这些角色的本职工作都应该为行业业务服务，行业的深度分析，快速响应市场，稳定的产品质量这些是必须要具备的。
但这就要求技术具备更快的迭代速度，业务推出速度从按周提升到按小时，每月上线业务量从“几十 / 月”提升到“几百 / 天”，并且不可接受业务中断。
另一个互联网企业需要云原生转型的原因是中国的刘易斯拐点已经到来。刘易斯拐点，即劳动力过剩向短缺的转折点，是指在工业化进程中，随着农村富余劳动力向非农产业的逐步转移，农村富余劳动力逐渐减少，最终达到瓶颈状态。用大白话说就是中国的人口红利已经逐渐消退，企业劳动力成本不断增加，加上 2020 年疫情的影响，成本因素越来越成为企业的重要考量。
而 SaaS 产品订阅制付费、通用性强、低部署成本的特点，便成了企业降本增效的新选择。这是 SaaS 企业在市场中的机会，而且对于 SaaS 企业本身来说，同样有降本增效的需求，而且内部降本增效做得越好，SaaS 产品在市场上的竞争力会更加明显。
以上这些现状的解法和云原生架构和核心能力不谋而合：
如何落地云原生架构
在聊如何落地云原生架构之前，我们先来看一看云原生架构成熟度模型（）：
云原生架构成熟度模型
云原生架构成熟度模型有六个评判维度，可以将成熟度划分为 4 个级别。我会从自动化能力、无服务化能力、弹性能力、可观测性、韧性能力这五个维度，贯穿说明如何落地云原生架构。
传统架构
上图展示的是一个较传统的 Java+ 架构应用服务侧的部署架构。除了 SLB，基本上所有的组件都部署在 ECS 上。下面我们来一起看看如何将这个架构转型为云原生架构。
无服务化（）
的概念是什么在这篇文章不再赘述，可以参阅进行了解。使用 ECS 集群部署服务的架构有两个显著的短板：
所以首先我们要将服务的部署方式 化，我们可以选择 App （SAE）作为服务应用的发布、部署平台。SAE 是面向应用的 PaaS 平台，能够帮助用户免运维 IaaS、按需使用、按量计费，做到低门槛服务应用云原生化，并且支持多种语言和高弹性能力。
1、命名空间
打开SAE 控制台，我们首先创建命名空间，SAE 的命名空间可以将其下的应用进行网络和资源的逻辑隔离，通常我们可使用命名空间来区分开发环境、测试环境、预发环境、生产环境。
2、创建应用
创建好命名空间后，我们进入应用列表，即可选择不同的命名空间，看到其下的应用或者创建应用：
选择对应的命名空间，然后创建应用：
配置完基本信息后，下一步进入应用部署配置：
我使用 Jar 包的方式部署完应用后，在对应命名空间下就可以看到刚刚创建的应用了：
点击应用名称可以查看应用详情：
3、绑定 SLB
因为 在架构中是对外提供接口的服务，所以需要对该服务绑定公网 SLB 暴露 IP 和做负载均衡，在 SAE 中，绑定 SLB 非常简单，在详情页中，即可看到应用访问设置：
添加 SLB 时可以选择新建也可以选择已经创建好的 SLB：
4、服务/配置中心
对于微服务架构，服务中心和配置中心是必不可少的，大家常用到一般是 、、 三种。对于云原生架构来讲，根据不同的场景，服务/配置中心可以有以下几种选择：
对于现状就是使用 的客户而言，转型云原生架构，服务/配置中心如上面表格所示有两种选择：
对于现状是使用 和 的客户而言，建议直接使用 MSE 和 MSE 。
这里我简单介绍一下 MSE。微服务引擎 MSE（ ）是一个面向业界主流开源微服务框架 和 一站式微服务平台，提供治理中心、托管的注册中心和托管的配置中心。这里我们用到的是 MSE 的托管注册中心和托管配置中心。
MSE 有三块核心的功能点：
弹性能力（）
云原生架构成熟度模型中的弹性能力同样依托于 SAE 来实现，因为 的底层实现原理，所以在 SAE 中的应用实例数（节点数）扩缩速度非常快，可达到秒级。
进入应用详情页的实例部署信息，可以看到应用的具体实例：
SAE 提供了两种扩缩应用实例数的方式，手动方式和自动方式。
1、手动扩缩
在控制台右上方有手动扩缩操作按钮，然后选择要扩缩到的实例数即可：
当进行扩缩时，我们可以看到具体实例的变更状态：
2、自动扩缩
在控制台右上角有自动扩缩操作按钮，然后可以看到创建扩缩规则的界面。SAE 自动扩缩提供时间策略和指标策略两种。
上图是时间策略，即设置好具体的时间节点，在这个时间节点要将应用的实例数扩到几个或者缩到几个。这种策略适合流量高峰期有相对明确时间节点的场景，比如在线教育的客户，通常流量高峰在晚上 8 点开始，11 点逐渐结束，这种情况下，通过定时策略在 7 点半左右把应用的实例数扩起来，然后 11 点之后逐渐把应用实例数缩回正常。
上图是指标策略，目前提供 CPU 使用率、内存使用率、应用的 QPS 阈值、应用接口平均响应时间（RT）阈值四种指标，这四种指标可以配合使用。当这四种指标其中有一种达到阈值后就会触发扩容，会对应用实例进行逐渐扩容。当指标小于阈值后触发缩容。这种策略适合流量高峰时间不固定的场景，比如市场营销，游戏运营。
3、成本优化
对于弹性能力，大家可能更多的是关注它能让系统快速支撑流量脉冲，增加系统横向扩展的能力。其实因为SAE有极致的弹性能力，再加上按分钟、按量计费的模式，对整体的资源成本是有一定优化的。
可观测性（）
应用侧的可观测性分两个维度，一是纵向的 指标，比如主机的 CPU、内存、磁盘各项指标，Pod 的 CPU、内存各项指标，JVM 的 Full GC、堆内存、非堆内存各项指标。另一个维度是横向的请求调用链路监测，上游服务到下游服务的调用、上游接口到下游接口的调用。
在监控微服务架构时，通常需要从三个角度来看：
而SAE对应用的监控也都覆盖了上述这两个维度和三个角度。
1、应用整体健康状况
进入应用详情页，点击左侧菜单中的应用监控/应用总览，便可以看到应用的整体状况：
2、应用实例节点健康状况
进入应用详情页，点击左侧菜单中的应用监控/应用详情，便可以看到应用每个节点的信息：
从上图可以看到，左侧会列出当前应用的所有实例节点，包括该节点的平均响应时间、请求次数、错误数、异常数。如果我们按照影响时间降序排序，比较靠上的节点就是响应时间较慢的节点，然后我们就需要分析是什么原因导致这些节点的响应时间较慢。所以，右侧会提供了一些检查维度来帮助我们分析排查问题。
比如查看 JVM 指标：
3、应用接口健康状况
进入应用详情页，点击左侧菜单中的应用监控/接口调用，便可以看到应用每个接口的信息：
接口监控和应用实例节点监控的思路一致，左侧会列出所有请求过的接口，同样显示了响应时间、请求数、错误数，右侧同样提供了一些检查维度来帮助我们分析接口 RT 高的原因。
比如查看 SQL 调用分析：
4、纵向 指标
在上述三个角度中，其实已经涵盖了绝大多数 指标，比如有应用健康状态的指标、JVM 的指标、SQL 指标、 指标等。
5、横向调用链路
在很多时候，我们单纯的看 指标是无法确定问题的根本原因的，因为会涉及到不同服务之间的调用，不同接口之间的调用，所以需要查看服务和服务之间、接口和接口之间的调用关系以及具体的代码信息。在这个维度上，SAE 集成的 ARMS 的监控能力便可以实现。我们在应用监控/接口调用/接口快照中可以看到有请求的接口快照，通过 便可以查看该接口的整体调用链路：
从上面这个图我们可以看出很多信息：
除了上述这些显性的信息以外，还有一些隐性的信息：
从以上这些信息可以帮我们缩小和圈定问题根因出现在哪个环节的范围，然后我们可以点击方法栈一列的放大镜，查看具体的方法栈代码信息：
从方法栈这里我们又可以得到很多显性信息：
当然除了显性信息外，还有一个比较重要的隐性信息，比如我们可以看到.n(int )这个方法的耗时是 5s，但是该方法内部的数据库操作的耗时很少，只有 1ms，说明耗时是属于业务代码的，毕竟业务代码我们是抓不到也不会去抓取信息的。这时我们可以有两种方式去定位具体问题：
韧性能力（）
对于云原生架构的韧性能力，我会从优雅上下线、多AZ部署、限流降级三个方面来聊一聊。
1、优雅上下线
一个好的产品，要能快速应对用户对产品功能、能力具有普适性的反馈和意见，能快速响应市场需求的变化。那么产品的功能就需要快速的做迭代和优化，从 IT 层面来看，就是要有快速、高效、高质量的发布变更流程，能够随时进行生产环境的服务发布。
但是这会带来一个核心问题，即频繁的服务发布，并且不能影响用户体验，用户的请求不能断流。所以这就要求我们的系统部署架构中有优雅上下线的能力。
以微服务架构来说明，虽然开源的产品有能力和方案做到近似优雅上下线，但也是近似做到，当发布服务节点较多的情况下依然会有断流的情况。所以开源方案有诸多问题：
在无服务化/服务配置中心章节中，我阐述了 SAE 自带的服务中心和 MSE 的服务中心，无论使用那种方案，我们都对优雅上下线做了进一步的优化。
从上图可以看到，部署在 SAE 的应用具有主动通知服务中心和服务消费者的能力，再结合 应用实例探活和 应用业务探活的机制，能让我们的服务在进行部署和因为其他原因挂掉时不会影响用户的正常访问。
2、多 AZ 部署
本着鸡蛋不能放在一个篮子里的原则，一个应用的多个节点，应该分布在不同的可用区，这样整体应用的高可用和健壮性才是足够好的。SAE 支持设置多个交换机（），每个交换机可以在不同的可用区，这样在部署、扩容应用的节点时会随机从可选的可用区拉起实例：
这就避免了当某个可用区出现问题挂掉时，整体系统因为在一个可用区而挂掉，这也是最基本的同城多活的实践。
3、限流降级
限流降级是系统断臂求生的能力，在遇到突发的流量脉冲时，可以及时限制流量云原生架构工程师，避免整个系统被击穿，或者当流量超出预期时，及时切断非核心业务，释放资源来支撑核心业务。
目前对于 Java 应用，SAE 也支持限流降级的能力，首先对应用的所有接口的请求指标进行抓取和监控：
然后我们可以针对每一个接口设置流控、隔离、熔断的规则，比如我对 / 接口设置一条流控规则：
当该接口的 QPS 达到 50 后，单个机器超过 50 的请求将快速失败。比如我们对一个有 6 个节点的应用进行压测时，可以看到每个节点的 QPS 情况：
当开启流控规则后，可以立即看到限流的效果：
可以看到 QPS 被精准的控制到 50，超过 50 的请求直接返回失败。
自动化能力（）
在自动化能力方面，我主要从 CICD 流程这个维度来聊一聊。大家从上面章节的截图可以看到，有很多是 SAE 控制台的截图，在实际应用中肯定不会通过控制台来一个一个发布应用，必然都是通过 CICD 流程来做自动化的应用打包和发布流程。
SAE 在这个方面提供两种实现自动化运维的方式。
1、基于 和
目前很多企业的 CICD 流程都是基于 和 来做的，那么 SAE 也支持将发布的操作集成到这种方案里。这个方案的核心是 SAE 会提供一个 插件云原生架构工程师，传统架构 vs 云原生架构，谈谈为什么我们需要云原生架构？，同时对应有三个配置文件， 插件通过这三个配置文件中的信息将打包好的 Jar/War 或者镜像发布到对应的 SAE 应用中。
更详细的配置信息可以参阅该文档。
然后在 的任务中，对 设置如下的命令即可：
clean package toolkit:deploy -Dtoolkit_profile=toolkit_profile.yaml -Dtoolkit_package=toolkit_package.yaml -Dtoolkit_deploy=toolkit_deploy.yaml
这样就可以很容易的将 SAE 的部署流程集成到基于 和 的 CICD 方案里了。
2、基于 Open API
还有一些企业会自己研发运维平台，运维赋能研发，由研发同学在运维平台上进行运维操作。面对这种场景，SAE 提供了丰富的 Open API，可以将 SAE 控制台上 90% 的能力通过 Open API 集成到客户自己的运维平台中。详细的 说明可以参与该文档。
总结
基于 SAE 武装过系统后，整体的部署架构会变成这样：
云原生架构成熟度模型（）在我阐述的这五个维度一共是 15 分，基于 SAE 的云原生架构在这五个维度会达到 12 分：
对于上手、实践、落地快捷简单，又能达到比较好的云原生架构成熟度的 SAE 方案，大家还在等什么呢？一起实践起来吧。
(欢迎大家加入知识星球获取更多资讯。)
联系我们
本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请添加站长微信举报，一经查实，本站将立刻删除。
如若转载，请注明出处：http://www.zhiyeeedu.com/32947.html
