10月23日，全球边缘计算大会·上海站在上海市长宁区天山西路舜元会议中心顺利召开。谐云作为此次大会合作伙伴，受邀并出席大会，边缘计算负责人魏欢于23日下午在会上发表“边缘计算大规模落地实践”的主题演讲。

全球边缘计算大会GECC是由边缘计算社区主办的边缘计算领域顶级盛会，至今已在北京、深圳等多地成功举办。此次上海站设置了1个主会场，3个分会场，邀请到政、产、学、研、用各界专家者布道分享，共同促进边缘计算领域知识传播与生态建设。

“边缘赋能”典型场景下，为满足更广连接、更低时延、更好控制等需求，云计算正在向一种更加全局化的分布式组合模式进阶，分布式云成为发展新模式。

开源基因，持续深耕，边缘计算的布道者

在边缘计算领域深耕五年，谐云积极参与分布式云、云边协同、边缘智能和边缘安全的生态共建，是云边协同产业方阵首批共建单位成员，参与信通院云边协同多个技术标准制定。深度参与边缘计算开源工作，贡献多个核心功能，在KubeEdge、OpenYurt项目源码均有极大贡献。此外，副总裁才振功还是云边协同产业方阵指导委员会委员。

谐云边缘计算解决方案，通过EdgeStack智能边缘计算平台保障稳定性，EdgeBox边缘一体机确保边缘安全，并准许物联网设备接入实现丰富的场景应用开发。

谐云EdgeStack®智能边缘计算平台的“云+边缘+端”的云边端协同架构，将容器云计算能力下沉至边缘节点，可支撑百万级边缘节点和设备接入，专为大规模、多接入、低带宽、低时延、高性能、高稳定等边缘计算场景倾力打造。谐云自主研发的EdgeBox边缘一体机，将云端的能力下沉到边缘侧，解决边缘实时性、可靠性、运维经济性等方面遇到的问题。可助力用户实现“降本增效保安全” 的建设、管理目标，使用户真正感受到“云边协同”所带来的全新价值。

多行业、丰富场景大规模落地验证

目前，谐云边缘计算解决方案已实践于分布式云、物联网、车云协同、边缘智能金融等多场景，为边缘计算领域树立了实践标杆和经典案例。在一些典型行业如通信、交通、金融、军工等多个行业领域中得到大规模的落地验证。

通信领域，谐云为行业巨头某在线服务公司业务场景定制开发、打造了云边协同平台，助力其轻松应对流量洪峰；交通领域，联合上汽集团商用车技术中心打造了“基于容器的下一代车云协同架构”，是汽车行业的首款“云、边、端”一体化架构，可实现百万级车联网大规模接入；为某跨海大桥打造了一体化协同的产品，积累了丰富的“边-端”设备协议对接经验，交付了行业顶尖的“软硬一体化”的整体解决方案。

此外，通过赋予边缘节点AI能力，为某银行搭建云边协同平台轻松纳管边缘节点与设备，降低时延，实现成本缩减与效率的飞升。其中，某在线服务公司和上汽集团案例还分别荣获《2020年分布式云与云边协同十佳实践案例》奖项和《2021年分布式云与云边协同十佳实践案例》奖项。

作为国内为数不多掌握底层核心技术的云原生解决方案提供商，谐云始终坚持以云原生技术为核心，同时从云向边缘基础设施延伸，扩大云的范围，建立云原生产品生态、整体解决方案和产业应用相结合的完整生态体系。

未来，谐云将继续潜心深耕云边协同，探索云边协同技术与更多行业的融合落地，推动云边协同生态发展和产业落地。

2021杭州云栖大会于10月19日～22日在杭州云栖小镇举办。谐云作为阿里云的核心合作伙伴，受邀并亮相21日的云原生峰会，谐云CEO王翱宇在现场进行了“深耕云原生技术：Kubernetes应用渐入佳境”的主题演讲，分享云原生领域前沿的创新与经验，探索数字化科技的新趋势，为数字化建设增添云力量。

云原生，进入后Kubernetes时代

云原生是面向云应用设计的一种思想理念，是云计算领域炙手可热的主流技术，极大地释放了云计算红利，成为发挥云效能的最佳实践路径。随着全行业上云的逐步深化，云计算的发展应用已进入云原生阶段。

云原生技术往往具有极致的弹性能力，以容器技术为基础的云原生技术架构可实现秒级甚至毫秒级的弹性响应能力，具有服务自治和故障自愈能力。基于云原生技术栈构建的平台具有自动化的分发调度协调机制，可实现应用故障的自动摘除与重构，具备大规模可复制能力，可实现跨区域、跨平台甚至跨服务商的规模化复制部署。

云原生技术的全面落地实践

云原生是企业的下一代基础设施平台，也是企业数字化转型的必然选择和出路，企业数字化转型必然走向云原生。云原生一直处于不断变化和发展的状态，如今随着云原生技术逐渐走向成熟，并在多个行业落地，各行各业对云原生的接受程度越来越高，云原生的落地标准也发生了变化。从之前的以落地k8s作为云原生典型标志转变成了业务全面落地云原生平台作为标志。因此，用户的关注点也从之前的如何搭建一套稳定、可靠的k8s平台转移到了如何让业务快速、稳定的在云元生平台落地、并且长足发展。

从应用价值来看，云原生实现了异构资源标准化，加速了企业数字基础设施升级，提供了业务应用的迭代速度，使云资源和应用更“便宜”。

从产业融合来看，云原生为其他信息技术大规模应用提供了重要支撑，能够为区块链、人工智能、大数据、边缘计算等新兴技术提供部署环境和基础支撑能力，对于建设融合、共赢的产业生态具有促进作用。

谐云✕阿里云打造OAM技术体系

谐云率先实现了基于OAM（开放应用模型）的可视化编排，给阿里云全球云原生生态事业填上了完美的一笔，成为全球首款基于OAM的应用可视化编排平台。

谐云联合阿里推出的OAM（开放应用模型），直接部署在物理机上，完全以应用为中心，让Kubernetes与底层资源打交道，对应用完全屏蔽掉底层资源的异构性，使得简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。

相信未来应用的构建会越来越简单，应用部署也将更贴近用户，基础设施的选择会根据用户的架构需求自动匹配。用户可以真正享受到云平台化的红利，快速复用已有的模块化能力，而OAM也将成为应用云原生化的必然选择。

随着业务需求和场景的增多，以及技术的不断发展，容器应用衍生出了边缘计算、安全、全链路监控等一系列云原生相关技术。谐云也针对技术的演进更新迭代出了边缘计算平台、云监控、云安全等一系列产品。凭借多年的云原生技术积累和客户需求场景实践，重点对以下几个领域进行了深度的技术耕耘和产品打磨：

1.面向分布式云的边缘计算平台：解决边端机器和设备的计算资源管理和调度问题。

2.基于EBPF的容器监控平台：解决云原生应用的全链路监控问题。

3.基于中间件的可视化运维管理平台：解决在应用云原生化之后的中间件的快速供给和自动化运维的问题。

谐云产品采用相同的底层技术架构，可根据客户业务特点、场景需求进行组合，提供高度契合的技术架构、网格布局、数据存储等方案，为企业提供多种场景下的一站式云原生解决方案。

谐云将持续秉承创新研发国产自主云原生操作系统的创业初心，深耕云原生底层技术，实现产品、服务、咨询、落地全覆盖，加速企业数字化转型，携手拥抱云原生。

2021 年 10 月 11 日，博云正式开源 Carina 本地存储方案，Carina 基于 Kubernetes 及 LVM 实现，提供了数据库与中间件等有状态应用在 Kubernetes 中运行所必须的高性能的本地存储能力，极大减少了存储系统的运维压力。今年9月，Carina 还以首批成员身份加入了由中国信通院发起的可信开源社区共同体，并获得可信开源项目成员证书。

Carina 最大的特点是高性能和免运维，为中间件、数据库等有状态服务提供了匹配本地磁盘的高 IOPS 和极低延迟的性能指标，同时易安装、自运维能力又极大的减轻了存储系统的运维压力。另外，Carina 还提供了本地磁盘管理能力、PV 高级调度能力、PV 自动分层技术、卷拓扑能力、自动 failover 能力、动态 IO 限速、监控告警、多种存储供给能力等高级功能。

功能亮点

• 灵活高效的供给高 IOPS、低延迟的存储
• 免运维，自动管理本地磁盘、自动组建 RAID
• 多种调度策略可配
• 支持带宽 IOPS 限速
• 支持 PV 数据自动分层
• 支持 PV 自动扩容
• 支持 RAID 管理能力
• 支持容灾转移能力
• 提供块和文件的访问方式

Why Carina？

• Kubernetes原生支持

完全兼容的 Kubernetes API ，无需额外开发，依赖组件很少且均为通用开源组件。

• 本地磁盘管理

自动管理本地磁盘，提供 RAID 组建、数据分层、磁盘限速等高级功能。

• 设备注册

将本地磁盘注册为 Kubernetes 设备，参与容器调度评分。

• 容灾转移

支持在节点删除，将存储卷在其他节点重建。

• 文件和块存储

同时支持为容器提供文件存储和块存储，以及在线扩容。

How it works

云端是标准 Kubernetes 集群，可以使用任何 CSI 存储插件，比如 Ceph-CSI。在集群中运行carina-controller carina-scheduler 在每个节点运行carina-node。

Carina主要有三部分组成，分别是carina-controller、carina-scheduler和carina-node，其架构图如下所示：

• 如上图架构所示，Carina 能够自动发现本地裸盘，并根据其磁盘特性划分为hdd磁盘卷组及 ssd 磁盘卷组等，针对于本地数据高可用，Carina 推出了基于 bcache 的磁盘缓存功能以及自动组件 RAID 功能；
• Carina-node 是运行在每个节点上的 agent 服务，利用 lvm 技术管理本地磁盘，按照类别将本地磁盘划分到不同的 VG 卷组，并从中划分 LV 提供给 POD 使用；
• Carina-scheduler 是 kubernetes 的调度插件，负责基于申请的 PV 大小，节点剩余磁盘空间大小，节点负载使用情况进行合理的调度。默认提供了 spreadout 及 binpack 两种调度策略；
• Carina-controller 是 Carina 的控制平面，监听PVC等资源，维护PVC，LV之间的关系。

Carina VS Ceph-CSI / NFS-CSI

Carina 不同于 Ceph-CSI，NFS-CSI 等 Kubernetes 网络存储插件。这些插件为网络存储插件，解决了应用在 Kubernetes 场景下数据跟随的问题，而 Carina 解决的是在数据库和中间件场景下对挂载设备高性能读写的问题。

Carina 应用场景

• 场景一：数据库 Redis、Mysql

Redis 作为高性能的内存型数据库缓存服务，同样有数据落盘的需求，而使用网络存储往往有比较大延迟，在使用 Carina 情况下，能够提供和读写本地磁盘一致的性能。Redis 主从模式其本身已经解决了数据多地备份的问题，Carina 并不会提供更多冗余的数据备份，节省了磁盘空间。Mysql 作为严重依赖存储的数据库服务，使用 Carina 提供的存储卷使 Mysql 在云上运行可以获得更接近在物理机上运行的性能。

• 场景二：消息服务 rocketmq、activemq

大多数消息中间件都是基于内存的，为了维持消息不丢失，消息中间件还是有落盘的需求，比如对于需要 ACK 应答的消息中间件，若是消息非常多，消息服务一般会选择将时间较久的消息落盘，对于消息中间件来说对磁盘性能要求可谓极高，Carina 恰恰提供了等同于本地磁盘的读写性能，且对于消息中间件并未有多副本存储需求，因此 Carina 也避免了存储多副本带来的性能消耗.

• 场景三：普通应用 POD

Carina 的部署、运维、使用极其简易，可以被当做一般项目的本地存储使用，相当于 hostpath 。与 hostpath 不同的是 hostpath 要求在宿主机建立相关存储目录。Carina 则完全不用关心节点机器，直接创建原生 pvc 即可。

随着越来越多的用户将业务向公有云上迁移，用户在为应用选择存储时，经常会陷入困境。企业每年数据量快速增长，开销越来越大；私有云中的数据和公有云中的数据、或者多个公有云之间的数据难以流动形成统一整体；同样的数据在面对不同的应用有着不同的性能、功能诉求，而公有云上的存储类型只能照顾一类应用，当另外的应用需要使用这组数据时，只能创建另外一套存储资源，需要面临数据拷贝的繁琐过程并管理这些数据集之间的同步问题。以上这些难点问题并不是一家公有云本身就能很好解决的，因为这涉及到线上/线下、存储产品的定义等问题。

焱融科技在服务大量线下用户的同时，一直关注公有云上的应用场景和技术创新，希望可以为公有云用户提供全新体验的第三方共享文件存储服务。于是，焱融科技于正式推出 SaaS 化的云舟共享数据服务。

01 云舟是什么

云舟是焱融科技构建在公有云基础架构上的 NAS 共享数据服务，支持多个主流的公有云。用户通过注册，就可以在云舟平台上，为不同公有云上运行的业务创建自己的共享文件存储空间。通过简单几步，就可以将这个存储空间共享至自己独立的租户和 VPC 内，应用程序可以使用 NFS 或 POSIX 私有协议客户端（即将推出）访问这些数据。云舟具有以下特点：

• 额外资源零消耗。有别于其它基于公有云的第三方 NAS 存储产品和方案，用户无需为云舟共享文件存储空间创建任何额外的云主机或存储资源，所有的存储资源实现真正的按需使用，数据在云舟平台上进行统一管理。
• 低成本，用户不再为账单发愁。焱融科技在云舟平台上，借助有效的数据生命周期管理技术，极大降低用户使用共享文件存储的成本，远低于公有云原生的共享文件存储。注册即可获得代金券，覆盖大多数中小企业和开发者一年的共享文件存储费用。
• 兼顾容量和性能。用户数据存储在云舟统一管理的空间上，当应用需要更高性能支撑时，只需将共享文件空间从容量型转为性能型即可，无需进行任何拷贝，文件存储类型无缝切换。

02 你会是云舟的用户吗

云舟的共享文件存储服务，为公有云广大用户提供了区别于公有云上原生的文件存储之外更灵活的选择。80% 的中小企业用户，共享文件容量在几 TB 到十多 TB，云舟可以无缝对接当前使用文件存储接口的业务应用，总体成本降低 30-40%，对于需要从精细运营中获取效益的中小企业来说，无疑是更好的选择。

公有云上还有大量的开发者用户，这些用户使用公有云来开发自己的应用程序，甚至是人工智能等需要使用到高性能文件存储的应用。对个人开发者来说，数据量通常来说并不大，但如果要在小容量情况下满足一些高性能应用的需要，无论是自己搭建 NFS 服务、还是使用公有云的共享文件存储，都难以得到理想的性能，甚至会拖慢 GPU 等计算资源，带来更大的成本开销。云舟可以为用户提供小容量、高性能的服务，对开发者来说，可以灵活调整所需的性能。只要你在公有云上需要共享文件存储，云舟就可以成为你的选择。

03 面向的市场和云舟的未来

在公有云上，块存储是云主机和其它很多应用场景的最重要基石。自从 AWS 推出 S3 对象存储之后，各家公有云也都将对象存储纳入必须具备的服务清单中，现在也很难看到没有对象存储的公有云。与之形成对比的是，在文件存储领域，各家公有云处于不同的阶段，所提供的共享文件存储的能力和服务也有较大差异。这是由于文件存储需求量大，但不同应用对文件存储的读写特点不同，公有云厂商众口难调，只能提供通用类型的文件存储产品和服务，这就为第三方存储厂商提供了施展的舞台。事实上，文件存储也是公有云上第三方存储最活跃细分领域。在国外，有不少厂商都在云上为用户提供有特色的文件存储服务，其中就包括大名鼎鼎的 NetApp。

IDC 等研究机构在多份报告中指出，第三方厂商有大量机会在公有云资源之上提供企业级文件存储服务。据 IDC 统计，2019年起，用户在公有云文件存储的支出每年增长 153%，这个数据清楚地表明，越来越多的用户将企业级应用程序迁移和部署到公有云上，并使用基于文件的共享存储。焱融科技在面对快速增长的市场和用户需求上，将 YRCloudFile 成熟的平台和技术创造性地部署在公有云上，针对公有云的特点，经过软件架构调整和长时间测试，推出了云舟共享数据平台。云舟首先解决用户的文件共享需求，通过分层技术降低用户使用成本，让应用不需任何改造就能完成对接。在此基础上，云舟很快会推出高性能 POSIX 客户端访问，并结合更多应用场景为用户带来性能和使用上的优化体验，提供便捷的操作接口，让开发者深切感受到云舟带来的便利。云舟 SaaS 数据服务平台，可以作为用户搭建分布式文件系统和公有云原生文件系统的替代，适用于以下场景：

• 高性能计算/人工智能：POSIX 兼容，可以支持所有机器学习、深度学习框架；共享能力提升团队管理、使用数据效率。
• 共享文件存储：没有客户端并发读写限制，可以并发共享存储访问。
• 数据备份：平滑扩展的存储空间，满足数据备份需求。
• 容器持久化：容器集群将容器镜像的配置文件或初始加载数据存储在共享文件存储上，在容器批量加载时实时读取。多 POD 间通过存储共享持久化数据，在 POD 故障时可以进行故障切换。

云舟是一个快速迭代的数据平台，每一个用户都是焱融科技最珍视的资源。注册试用后，用户有任何意见和想法，都可以反馈到社区中，任何反馈对产品改进都是最大的的推动力。

焱融科技希望通过云舟产品能聚集成围绕云的更强大的数据生态，相信在云舟平台上会诞生最酷的创意和应用。

关于百胜中国

自从1987年第一家餐厅开业以来，截至2021年第二季度，百胜中国在中国大陆的足迹遍布所有省市自治区，在1500多座城镇经营着11023家餐厅，员工人数超过40万。旗下有知名品牌肯德基、必胜客等多个品牌。

选择Rainbond

百胜中国技术团队一直在寻求一款可以简化K8s操作的图形化工具，可以摆脱K8s复杂的使用方式，并将应用运维和资源运维解耦。这样可以让技术团队专注于应用系统本身，极大降低整个部门的成本投入。通过InfoQ上的文章，百胜中国技术团队了解到了 Rainbond 这款产品，文章中对 Rainbond 的介绍非常契合他们的需求。

在对比过 Rancher、青云等产品后，百胜中国企业应用团队最终选择了 Rainbond 作为企业应用管理平台。最终打动百胜中国企业应用团队的，是Rainbond非常易用，容易上手。

Rainbond和Rancher各司其职

在实践过程中，技术团队将 Rainbond 与 Rancher 两款产品充分融合使用，Rancher 和 Rainbond 本身并不冲突，或者说是相辅相成的，这两个工具共同解决了企业应用团队内部不同纬度的运维需求。Rancher 并不是从应用视角出发的，但从底层运维的角度来看，Rancher非常专业，包含很多角度监控报警。如果资源运维团队想去看一些东西，则使用 Rancher 去管理；而从应用视角，则会用Rainbond 去管理。

IT流程一体化管理，供应商软件持续交付

百胜中国IT团队借助Rainbond搭建一体化管理流程，在这个流程中，外部供应商进场后直接被分配指定的工作租户，供应商可以将经过其它 CI/CD 系统生产出的镜像快速部署到当前租户中去。经过将若干业务组件进行简单的拼装，就生产出了一套基于 ServiceMesh 微服务架构实现的完整业务系统。经过测试后，百胜中国企业应用团队就可以将业务系统整体发布到中台组件库中，将软件以应用模板的形式保存下来。在最终的生产租户中，只需要一键，即可将外部供应商的业务系统安装运行起来，供应商有新的版本持续发布到中台组件库，生产系统根据需要滚动升级，自动化运维能力加强了IT团队对生产系统的管理能力，尤其是自动伸缩功能在业务高峰期的表现非常亮眼，最终面向企业内部用户提供 SaaS 化的服务。

应用场景1: 更安全的供应商管理

百胜中国IT团队面对着大量的外部供应商。通过 Rainbond 提供的租户隔离能力，外部供应商可以在属于自己的完全隔离租户内完成应用的迁移部署工作。通过中台组件库，百胜中国企业技术团队可以把外部供应商部署完成的完整企业应用以应用模板的形式，流转安装到生产集群的生产租户中去。这样做的好处是阻绝了外包厂商操作最终生产环境，提高了企业IT设施的安全性。

应用场景2: 软件资产化管理

软件资产现在已经成为企业IT资产的重要组成部分，越来越受到管理人员的重视。然而多数软件系统在厂商维保期过期之后的安装、运维都成为了软件资产管理的极大障碍。Rainbond的组件库存放所有应用系统，保存应用系统的所有历史版本，使用时一键安装和升级，让软件的价值在企业内部流动起来 ，使得百胜中国IT团队面对软件资产管理工作时游刃有余。

应用场景3: 敏捷的企业资源管理

百胜中国IT团队日常工作中负责为外部供应商提供计算资源。在以往，从对计算资源需求的提出，直到服务器落地，企业应用的部署，往往需要数月时间。引入 Rainbond 作为企业应用管理平台之后，通过将计算资源池化管理，实现外部供应商可以随时进场部署的同时，极大的节约了计算资源的使用，原计划3个月完成上线的物流订单管理中台，借助 Rainbond 在1个月内就完成了迁移上线。

应用场景4: 以SaaS的方式对内提供服务

为了适应新的采购和管理模式，百胜中国IT团队借助 Rainbond 的能力，将所采购的软件服务化，以 SaaS 的形式提供给公司内部使用。这一改动极大的提升了最终用户的使用体验，也降低了企业应用系统的维护成本。

应用场景5: 供应商应用系统验收

好雨科技交付团队为百胜中国企业应用团队提供了一套完整的云原生应用准入规范，这一规范指引了外部供应商如何将自己的应用系统改造成为更符合云原生时代特征的应用，符合规范才能验收，准入规范不仅降低了对供应商的依赖度，同时也让云原生的价值更好落地。

使用总结

Rainbond正在百胜中国IT团队内部扮演越来越重要的角色，目前已经运行着多套企业应用系统。在好雨科技交付团队的辅助下，百胜中国IT团队依托 Rainbond 搭建起完整的企业应用交付落地的全流程。

Rainbond及好雨提供的的企业服务也得到了百胜中国的认可：

好雨的服务响应比较快，交付团队特别热情。在整个POC测试阶段到最终上线生产，遇到问题能保障及时响应、快速修复上线。还有一些功能上的定制开发，Rainbond开发团队也能及时完成需求。比如某业务迁移过程中需要组件之间支持 Grpc 协议的负载均衡，从提出需求到测试上线，一共没超过3天，没有耽误整体进度。Rainbond从 POC 测试到现在正式上线运行已经过了一年，整体运行情况比较稳定。

未来计划

双方将继续合作，在存储兼容性、容器安全等领域持续打磨企业应用管理平台，百胜中国企业IT团队也将继续推广 Rainbond 在公司内部的使用范围。双方正在规划下一阶段多数据中心多活的落地方案。这一举措将极大的提升百胜中国企业应用的稳定性与可用性。

关于 Rainbond

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

已有上百家企业使用Rainbond管理关键业务场景，涵盖制造、能源、高校、公安、政府、交通、军工等十几个行业。客户有 京东方、百胜中国、中航信、中公高科、拓维信息、联影医疗、中海创等大型企业。

导读：

之前提过要做一个 API 网关的介绍，事实上，无论是微服务、服务网格，还是云原生、数字化的建设，API 网关都是绕不开的话题。介于网上对于 API 网关的介绍参差不齐，所以今天我们不再简单的做 API 网关基础知识与功能介绍，而是直切要点，聊聊 ESB、ServiceMesh、 微服务与 API 网关的关系。

01

API 网关的核心

随着微服务场景的普遍运用，API 网关也逐渐被大家所重视，聚合接口、聚合服务以提供前端调用、业务封装，这是 API 网关的主要场景。

API 网关处于业务内外通信或系统前后端的桥梁，功能上除了建立通信、路由转发以外，也承担了许多非业务的功能，比如安全、流控、过滤、缓存、监控等；在服务化模式下，也会增加一些运营的功能，比如 API 管理、计量计费、服务订阅等等。

可见，在 API 网关上我们可以做很多文章，只因它对流量做了承接和转发，这也是 API 网关的核心。

这样的角色并不陌生，在我之前的两篇文章中提到的 ESB、ServiceMesh 都有借助流量的承接转发功能，然后形成的解决方案。同一件工具，被置于不同的位置，就有其不同的形态，API 网关就是这样的工具。

02

API与ESB 、ServiceMesh、微服务的关系

替代ESB的场景

ESB 没必要再做深入的介绍了，其核心也是路由、转发、转换、流控。在当下ESB 逐步退出数字化的舞台的同时，多数企业也在思考如何通过一个替代品逐步替换 ESB，我们博云就在多个项目中分别通过微服务框架、服务网格框架做出过多种平滑接替 ESB 的方案和功能。同时覆盖其原有的路由转发、协议转换、限流控制的功能，最直接的方案就是通过 API 网关实现。

ESB 的架构，同时承担了东西向服务间的访问控制，和南北向流量的控制。而使用了 API 网关的方案就显得更加灵活了，其可大可小的体量、动态配置的灵活特性、自服务的消费模式，都更能符合多变多样化的新型数字架构。如果规划得当，API 网关在替代 ESB 的同时，也可以作为整个网络域内，甚至整个企业级的网关，这也就是服务中台化的第一步。

服务网格中的应用

ServiceMesh 的理念其实很容易理解，通过一个代理服务，将所有的流量接管，同时将非业务的治理、监控等功能，都通过代理服务实现。那么这个代理服务（proxy），就是 API 网关的另一个运用场景。劫持流量，然后加入所需的定制化功能。

与其他场景相比，这里的网关功能上没有太大的变动，但是使用位置却有很大差别。在 ServiceMesh 场景中，网关是一个很小很轻量的代理单元，而每个业务运行单元都会搭载该代理单元共同启动，所以在 ServiceMesh 场景中，通常叫做边车（Sidecar）。也就是说 ServiceMesh 中的 Sidecar 就是一个 API 网关的应用，比如 Istio 框架下，数据面 Sidecar 就是 Envoy（基于C++语言的 API 网关）。

微服务网关

值得一提的是微服务场景下的 API 网关，这种场景难道不是最基本的运用吗？其实不然，微服务网关也是对 API 网关的场景化改造后的结果，比如SpringcloudGateway、Zuul 这两种是基于 netty 框架的 Java 语言开发的微服务网关，主要在 Springcloud 微服务的场景下使用。

微服务场景下，服务间通信的寻址都需要依赖于注册中心，微服务网关做路由转发的时候，上游地址也需要从注册中心获取，同时微服务访问网关的时候也可以直接通过注册中心寻址，因此微服务网关需要符合微服务框架的注册与发现机制。

03

总结

三种网关核心都是通信的代理和转发，替代 ESB 的时候带上协议转换的特性，对接微服务的时候增加注册中心同步的功能，做为 Sidecar 的时候需要做流量劫持以及控制面的通信。另外还有没提到 API 市场的场景，这种场景就需要补充计量计费等功能了。

所以根据不同的使用场景、不同的运用方式，依赖于 API 网关都可以自由调整。在我们博云内部，就至少涉及了三种网关和多种场景的使用。

• 第一种：企业级的 API 网关，主要注重服务能力的提供，承接全企业的流量，因此对于网关的性能有极高的要求。我们采用的组件是基于openresty+lua 的 kong 来解决，性能上保证全企业的交互压力。
• 第二种：微服务的网关，主要是微服务的封装，但是不是重点和难点，通过很多个项目的交付发现，微服务的需求容易满足，而过渡方案比较难。所谓过渡方案是指非微服务的应用，在需要与微服务应用统一治理时，通过 API 网关做的 Sidecar 方案。我们博云内部采用的是 SpringcloudGateway，并在其上做协议转换、服务检测等功能，实现对单体应用、传统架构系统的统一纳管和治理。
• 第三种：服务网格，主要是数据面 Sidecar 部分，与之上的区别是，之上的微服务框架基本已经确定是 Springcloud，而服务网格本在我们博云内部采用的是 Istio 框架，Istio 框架下 Sidecar 采用的是 Envoy 。我们在 Envoy 上拓展 ESB 的场景、传统架构兼容的场景，并增加协议支持、协议转换、数据收集、链路收集等功能，以实现复杂的微服务转型需求。

阵而后战，兵法之常，运用之妙，存乎一心。API 网关的技术已经几于成熟，在合适的场景下合理的运用将会发挥极大的作用。

​1.关于柯基数据

南京柯基数据科技有限公司成立于2015年，提供一站式全生命周期知识图谱构建和运维、智能应用服务，致力于“链接海量数据，从大数据中挖掘智慧“。帮助企业运用知识图谱技术打造世界领先的认知工作自动化智能引擎。

目前在药企、医疗机构、军工院所、科技情报及出版等领域服务了数十家大客户，积累了丰富的行业知识图谱运用开发经验。典型客户有国防科技大学、中国航空、中国电科等。

2.柯基数据的云原生之路

大家好，我是南京柯基数据的解决方案架构师刘占峰，云原生技术在交付运维上的优势让我获益匪浅。作为项目合作伙伴，Rainbond持续助力柯基多套业务系统的快速开发和交付部署。在使用Rainbond之前，由于业务迭代周期短，涉及组件多，平台版本更新耗时耗力，服务运维难度大。很多项目中，客户的运维能力储备不足，基于传统的交付和管理方式，客户对于业务运维根本接管不起来，只要风吹草动，必须要我们派工程师到现场解决。针对交付运维存在的问题，各个业务平台开始着手云原生改造。

最开始我们尝试自己搭建公司内部的开发测试环境，过程中遇到的两个小坑。

第一个坑是：环境搭建完成后使用体验却不佳，所有涉及到磁盘读写的操作都显得异常卡顿，集群中的 Etcd 集群日志中不断报告处于 “read_only” 状态，随之而来的是服务器负载的不断飙升。

我们带着怀疑的心情求助了Rainbond开源社区，经过多方面的排查，我们把目光落在了磁盘的IO性能上。替换了高性能的磁盘之后，我们重新安装了整个开发测试环境，磁盘性能的提升的确解决了 Etcd 集群时常不工作的问题。

第二个坑是：使用了共享存储的服务却依然处于读写极慢的状态，这着实令在场的所有工程师又开始头大了。确认了硬件性能之后，开始将目光放在操作系统配置参数上面，操作系统内核在不断报告与共享存储有关的错误：

NFS:__nfs4_reclaim_open_state: Lock reclaim failed!指征 nfs client 和 nfs server 之间存在同步差异，差得多了就会开始报警。经过不断摸索，工程师们终于锁定了与 nfs 性能有关的两个系统参数，Linux nfs 客户端对于同时发起的NFS请求数量进行了控制，若该参数配置较小会导致 IO 性能较差。

echo “options sunrpc tcp_slot_table_entries=128” >> /etc/modprobe.d/sunrpc.conf

echo “options sunrpc tcp_max_slot_table_entries=128” >> /etc/modprobe.d/sunrpc.conf

修改了这两个参数后，共享存储的性能得到了显著的提升，令人摸不到头脑的内核报警信息也随之消失。开发测试环境终于可以顺畅使用了。

接下来面临新的挑战是如何将我们的多套业务系统顺利迁移到 Rainbond 上去，所幸Rainbond 的使用很简单，整体学习梯度并不陡峭，我们很轻松把业务系统分批的部署在 Rainbond 上去。然而 Rainbond 工程师组织的云原生应用评估却指出了业务系统有多处不符合云原生特征之处，提出了一些整改意见。在整改过程中，我们对云原生也有了更深入理解。

• Elasticsearch等有状态组件需要将组件部署类型调整成为有状态单实例或有状态多实例，不可以是无状态我们最开始并不了解什么是有\无状态组件，所以并没有注意区分组件的部署类型。Rainbond工程师提示我们，Elasticsearch在Rainbond平台中应该使用有状态的组件部署类型进行部署。
  

  L1级云原生应用特征——可伸缩性

  云原生应用注重部署组件所使用的资源类型，像数据库类型、消息队列类型的服务组件对在Rainbond平台上，应该使用StatefulSet资源类型进行部署。通过对服务组件定义有状态或者无状态的部署类型，来规定使用StatefulSet或Deployment资源类型来部署实例。

• 支持横向伸缩我们的多套业务系统，在接触云原生改造之前，都是传统的单体架构，部署时也基本不考虑高可用特性。这使我们的业务系统相对而言脆弱许多，没有任何容错能力，一旦服务器宕机，整个业务系统就失去了服务能力。云原生改造的过程中，我们借助于Rainbond天然的微服务能力，非常轻松的将我们的业务系统拆分成为更为合理的微服务架构。更令我们惊喜的是，这些拆分出来的微服务组件，大多数直接具备了横向伸缩的能力，借助Rainbond的一键伸缩能力，迅速扩展成为多实例的集群，极大的提高了系统的可用性。而针对某几个不可以一键伸缩的组件，Rainbond工程师们也提供了合理的意见，引导我们对这几个特殊的组件进行修改，使之实现了“无状态化”。现在，经过云原生改造的业务具备了“小强”一般顽强的生命力，再也不怕服务器宕机了。
  

  L1级云原生应用特征——可伸缩性

  通过程序数据分离等手段，实现应用程序的无状态化，就让云原生应用可以随意横向伸缩多个实例。实例数量的伸缩一方面使云原生应用具备了高可用性，也直接影响其抗并发的能力。Rainbond还提供自动伸缩功能，实现削峰填谷。

• 所有配置支持环境变量配置，形如 ${GATEWAY_PORT:8083}以往我们都将服务的配置项写成固定的值，这样的做法使得我们每到一个新的部署环境，都要重新更改大量的配置文件。Rainbond工程师指出，云原生应用应该将配置保存到环境当中，以环境变量加默认值的方式声明出来。而大多数需要修改的配置项，如不同组件之间的连接地址信息，就可以通过Rainbond依赖关系中的连接信息来相互注入，省去了大量的配置工作。
  

  L1级云原生应用特征——可配置性

  云原生应用推崇的一种最佳实践，就是将配置保存在环境之中。在不同的运行环境中，利用环境变量来进行配置，是一种非常好的体验。Rainbond支持为每个服务组件设置环境变量，也可以基于配置组功能，批量配置环境变量。

• 组件主要端口通过环境变量  ${PORT} 定义Rainbond工程师提供了一个小技巧，将组件监听端口的配置，用一个固定的环境变量来配置，这个变量的值会随着我们在Rainbond控制台上手动添加的端口号来自动变更，这样，我们就可以在不更改代码和配置的情况下，随意变更想要监听的端口号，这很方便。
  

  L1级云原生应用特征——可配置性

  作为对环境变量的补充，Rainbond提供了一系列可以自动生成的环境变量，这些特定的环境变量极大方便了用户的使用。

• 所有组件需要统一时区统一所有组件的时区配置是非常有必要的，Rainbond工程师提供了一个技巧，让时区的设置变成了一个很简单的事情。只需要运行环境的镜像中包含 tzdata 软件包，我们就可以基于 TZ=Asia/shanghai 这样一个环境变量的配置，完成时区的配置了。
  

  L1级云原生应用特征——基础可观测性

  统一时间在运维领域十分重要，在云原生领域，时区的配置也可以基于环境变量进行配置。

• 所有业务需要定义健康检查策略Rainbond工程师要求我们为所有的服务组件定义健康检查策略，这样可以在服务组件遭遇问题时，快速识别到运行异常状态，在根据事先的配置，完成下线或重启的操作。对于 http 服务，我们定义了一个检测接口，通过探针请求返回的状态码来判断服务的状态；对于一般中间件，则检测其TCP端口的监听状态来判断。
  

  L1级云原生应用特征——高容错性

  在提高容错性方面，云原生应用需要配置合理的健康检查策略。这有利于快速发现组件的异常状况，并根据事先配置好的策略进行自动化的重启、下线等操作。

• 组件应支持优雅失败与重试机制Rainbond工程师向我们阐述我们的服务组件在被关闭时，应该做出怎样的反应，来最大化的优化最终用户的体验。进程接收SIGTERM时，拒绝新请求，完成已接收请求后关闭端口，退出进程。而对于服务组件突然丢失了数据库连接这样的情况，也应该添加合理的重试机制，在多次重试依然无法重新连接到数据库时，理应结束进程，用显式的组件异常状态来提醒运维人员。
  

  L1级云原生应用特征——高容错性

  云原生应用强调容错性，这不仅仅包含在某些错误被触发时，应用本身和平台是否提供自动的处理手段，也包括在错误无法被处理时，提供更好的可观测性，来提醒运维人员介入。

• 前端web组件调用后端api组件地址需要进行nginx代理对于前后端分离的项目，合理的利用前端的web服务器进行接口层的转发是一种很好的体验。Rainbond工程师在帮助我们完成前端VUE项目的源码构建的同时，也教学了如何通过在代码根目录下添加配置文件，来实现接口请求向后端组件的转发。
  

  L2级云原生应用特征——前后端分离配置

  Rainbond提供了便捷的方式来配置VUE等前端项目运行的Nginx，配置后只需要将前后端组件依赖起来，就可以实现API的转发。而不需要每部署一次，都要根据后端服务的地址变更而重新编译。

• 实现一键交付使用Rainbond的目的之一，是希望能够借助其能力，实现业务系统的快速交付。通过与好雨科技交付团队的合作，我们只需要提供应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键交付整套业务系统。这极大的降低了我们的交付成本。
  

  L2级云原生应用特征——一键安装

  借助于 Rainbond 提供的应用发布能力，我们可以将运行在平台上的企业应用一键发布为一个应用模版。我们对应用模版最殷切的期待，是可以将这个应用模版以最简单的操作方式、尽可能少的人为调试即可安装成为一个应用。

• 实现一键升级为了适应最终用户的需求，我们需要不断迭代自己的产品，并在生产环境中持续升级我们的业务系统。Rainbond 基于应用模板的版本实现了一键升级的能力，这个功能对我们非常有用，我们只需要提供更高版本的应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键升级整套业务系统。
  

  L2级云原生应用特征——一键升级

  Rainbond 的应用商店机制支持基于应用模板的版本对已安装的应用进行升级操作。平台的升级机制解决了服务组件版本、配置、依赖关系等绝大部份属性的版本管理问题。尚需应用开发人员关注的问题在于数据的版本管理。

3.最终效果

应用完成改造后，通过Rainbond可以查看我们产品的拓扑图和依赖关系。

在实际项目当中，我们产品流转了三个环境：

开发环境：我们在公司内部，使用开源版本的Rainbond在公司服务器上搭建了开发测试环境，我们开发团队通过源码构建，很快将业务系统搬上了Rainbond。通过一段时间的测试和迭代，我们拿出了首个版本的应用模板，并使用离线导出功能导出了离线包。

准入测试环境：利用光盘等介质，仅需一个工程师将离线包导入了最终客户提供的私有云准入测试环境，导入后产品一键安装。对于客户反馈的意见，我们在开发环境中导出新的离线包，并再次导入了准入测试环境，进行了一键升级，经过多次迭代最终达到客户的准入要求。

生产环境：最终生产环境是完全由客户管理，我们仅需要提供经过准入的应用模板离线包以及必要的文档，客户就可以非常快速的将我们的产品完成部署和升级。

相对于以前的交付方式和流程，接入Rainbond体系给我们带来了这些更好的交付体验：

• 更便捷的交付方式：交付物只是离线包，不需要关心客户复杂的运行环境。
• 更低的交付成本：无论从时间还是人力的角度，交付成本都极大的降低了。
• 应用运维过程自动化：云原生技术切实的提升了业务系统的各项能力，可用性、容错性以及应对流量陡增时动态的伸缩能力。

最终仅用一个星期，我们就完成了各个业务系统的云原生改造工作，并测试通过云原生应用标准规范认证L2级。之前项目交付过程中交付难、维护难的问题，是我们最大的隐形成本，客户只会看最终交付效果，并不会为交付过程而买单。

做了云原生改造后，之前需要派驻交付团队1个星期才能交付完的项目，现在一个基础的运维工程师刻盘过去安装，1小时就可以搞定。并且用户可以通过Rainbond的可视化界面快速上手掌握，95%的运维问题都可以自行解决，或者远程指导客户操作。

4.什么是云原生应用标准规范认证？

「云原生应用标准规范认证」为软件厂商的应用交付过程中的便利性、交付客户后的可维护性、以及必要时的可迁移性等需求，提供可信赖的技术背书。现阶段，「云原生应用标准规范认证」分为L1、L2、L3级，在应用交付及交付管理发挥重要作用。

• L1关注：应用跨环境交付后的一键安装和自动化运维。如高可用、可伸缩性、可观测性等，提升最终客户的可维护性，降低客户的学习成本。
• L2在L1基础之上关注：应用跨环境交付后的一键升级。如全量/增量升级、版本回滚等，满足客户小步快跑的持续迭代交付需求。
• L3在L2基础之上点关注：应用跨环境交付后的一键备份迁移。如包含完整数据的打包备份、可迁移性等，帮助客户实现整体生产环境的迁移、灾备。

5.关于Rainbond

Rainbond作为开源的云原生应用管理平台，是「云原生应用标准规范」落地实施的最佳工具。

https://www.rainbond.com

https://github.com/goodrain/rainbond

前言：

8 月 2 日，博云正式发布了 FabEdge 开源项目，这是一款基于 K8S 和 Kubedge 构建的针对边缘计算场景的开源网络方案。发布之后，FabEdge 受到很多开发者的关注，并对 FabEdge 提出了很多宝贵的建议。同时，我们注意到用户在安装部署 FabEdge 的过程中，遇到因为无法搭建 Kubernetes + Kubedge 集群，而无法体验 FabEdge 的挑战。

因此，针对这一问题，FabEdge 团队推出了一键部署 K8S 和 Kubedge 的功能，本期文章将介绍使用该功能快速部署集群，从而极速上手体验 FabEdge 项目。

FabEdge 安装指南视频介绍

 快速部署 K8S 集群

安装条件

• 遵循 kubeadm 的最低要求 ，Master && Node 最低 2C2G，磁盘空间不小于 10G；

  ⚠️注意：尽可能提供干净的机器，避免其他因素引起安装错误。

支持的操作系统

• Ubuntu 18.04.5 Server 4.15.0-136-generic （推荐使用）

• Ubuntu 20.04.2  Server 5.4.0-66-generic

• CentOS Linux release 7.9.2009 (Core)

• CentOS Linux release 7.8.2003 (Core)

部署 k8s 集群

1. 安装 k8s Master 节点

以 Ubuntu 18.04.5 系统为例子，运行以下指令：

root@master:~# curl http://116.62.127.76/FabEdge/fabedge/main/deploy/cluster/install-k8s.sh | bash -

⚠️注意：如果加载时间过长，表明网速较慢，请耐心等待

如果出现以下信息，表示安装成功：

PLAY RECAP *********************************************************************master                     : ok=15   changed=13   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

2. 添加 k8s 边缘节点

root@master:~# curl http://116.62.127.76/FabEdge/fabedge/main/deploy/cluster/add-edge-node.sh | bash -s -- --host-vars ansible_hostname={hostname} ansible_user={username} ansible_password={password} ansible_host={edge-node-IP}

参数说明：

• ansible_hostname   指定边缘节点的主机名

• ansible_user             配置边缘节点的用户名

• ansible_password    配置边缘节点的密码

• ansible_host             配置边缘节点的 IP 地址

  例如：设置边缘节点的主机名为 edge1、用户名是 root、密码是 pwd111、IP 为 10.22.45.26，指令如下：

root@master:~# curl http://116.62.127.76/FabEdge/fabedge/main/deploy/cluster/add-edge-node.sh |  bash -s -- --host-vars ansible_hostname=edge1 ansible_user=root ansible_password=pwd111 ansible_host=10.22.45.26

如果出现以下信息，表示安装成功：

PLAY RECAP *********************************************************************edge1                      : ok=13   changed=10   unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

3. 确认节点添加成功

root@master:~# kubectl get nodeNAME     STATUS   ROLES                   AGE     VERSIONedge1    Ready    agent,edge              22m      v1.19.3-kubeedge-v1.5.0master   Ready    master,node             32m      v1.19.7

⚠️注意：如果边缘节点没有配置密码，需要配置 ssh 证书。

master 节点配置 ssh 证书：

root@master:~# docker exec -it installer bashroot@master:~# ssh-copy-id {edge-node-IP}

FabEdge 部署

关闭 rp_filter

在所有云端节点执行下面命令：

root@master:~# for i in /proc/sys/net/ipv4/conf/*/rp_filter; do  echo 0 >$i; done​#保存配置root@master:~# vi /etc/sysctl.conf..net.ipv4.conf.default.rp_filter=0net.ipv4.conf.all.rp_filter=0..​#确认配置生效root@master:~# sysctl -a | grep rp_filter | grep -v arp..net.ipv4.conf.cali18867a5062d.rp_filter = 0net.ipv4.conf.cali6202a829553.rp_filter = 0..

查看 nodelocaldns 服务状态

• 确认所有边缘节点上 nodelocaldns 的 pod 启动正常

root@master:~# kubectl get po -n kube-system -o wide| grep nodelocaldnsnodelocaldns-4m2jx                              1/1     Running     0          25m    10.22.45.30    master           nodelocaldns-p5h9k                              1/1     Running     0          35m    10.22.45.26    edge1   

获取 Fabedge

root@master:~# git clone https://github.com/FabEdge/fabedge.git

为 strongswan 生成证书

• 为每个边缘节点生成证书， 以 edge1 为例：

root@master:~# kubectl get node  NAME    STATUS   ROLES                   AGE    VERSION  edge1   Ready    agent,edge              47m    v1.19.3-kubeedge-v1.1.0  master  Ready    master,node             57m    v1.19.7​# 云端执行，生成证书root@master:~# docker run --rm -v /ipsec.d:/ipsec.d fabedge/strongswan:latest /genCert.sh edge1  ​# 登录边缘节点，在边缘节点edge1上创建目录root@edge1:~# mkdir -p /etc/fabedge/ipsec root@edge1:~# cd /etc/fabedge/ipsec root@edge1:/etc/fabedge/ipsec# mkdir -p cacerts certs private ​# 将生成的证书copy到边缘节点, # 注意证书名字: edge1_cert -> edgecert.pem, edge1.ipsec.secrets -> ipsec.secrets# “edgecert.pem”，“ipsec.secrets” 是固定名字，不能改变root@master:~# scp /ipsec.d/cacerts/ca.pem          <user>@edge1:/etc/fabedge/ipsec/cacerts/ca.pemroot@master:~# scp /ipsec.d/certs/edge1_cert.pem    <user>@edge1:/etc/fabedge/ipsec/certs/edgecert.pemroot@master:~# scp /ipsec.d/private/edge1_key.pem   <user>@edge1:/etc/fabedge/ipsec/private/edge1_key.pemroot@master:~# scp /ipsec.d/edge1.ipsec.secrets     <user>@edge1:/etc/fabedge/ipsec/ipsec.secrets

• 为 connector 服务生成证书，并拷贝到运行 connector 服务的节点上， 以 master 为例：

root@master:~# kubectl get node  NAME    STATUS   ROLES                   AGE    VERSION  edge1   Ready    agent,edge              62m    v1.19.3-kubeedge-v1.1.0       master  Ready    master,node             72m    v1.19.7    ​# 在master上执行, 生成证书root@master:~# docker run --rm -v /ipsec.d:/ipsec.d fabedge/strongswan:latest /genCert.sh connector  ​# 在master上执行，创建目录root@master:~# mkdir -p /etc/fabedge/ipsec root@master:~# cd /etc/fabedge/ipsec root@master:/etc/fabedge/ipsec# mkdir -p cacerts certs private ​# 在master上执行，copy证书root@master:~# cp /ipsec.d/cacerts/ca.pem                /etc/fabedge/ipsec/cacerts/ca.pemroot@master:~# cp /ipsec.d/certs/connector_cert.pem     /etc/fabedge/ipsec/certs/connector_cert.pemroot@master:~# cp /ipsec.d/private/connector_key.pem   /etc/fabedge/ipsec/private/connector_key.pemroot@master:~# cp /ipsec.d/connector.ipsec.secrets    /etc/fabedge/ipsec/ipsec.secrets

创建命名空间

• 创建 fabedge 的资源使用的 namespace，默认为 fabedge，

root@master:~# kubectl create ns fabedge

部署 Connector

• 在云端选取一个节点运行 connector，为节点做标记，以 master 为例：

root@master:~# kubectl get node  NAME    STATUS   ROLES                   AGE    VERSION  edge1   Ready    agent,edge              107m   v1.19.3-kubeedge-v1.1.0       master  Ready    master,node             117m   v1.19.7     ​root@master:~# kubectl label no master node-role.kubernetes.io/connector=​root@master:~# kubectl get node  NAME    STATUS   ROLES                   AGE    VERSION  edge1   Ready    agent,edge              108m   v1.19.3-kubeedge-v1.1.0       master  Ready    connector,master,node   118m   v1.19.7     

• 修改 connector 的配置

按实际环境修改 edgePodCIDR, ip, sbunets 属性

root@master:~# vi ~/fabedge/deploy/connector/cm.yaml

data:  connector.yaml: |    tunnelConfig: /etc/fabedge/tunnels.yaml    certFile: /etc/ipsec.d/certs/connector_cert.pem        viciSocket: /var/run/charon.vici    # period to sync tunnel/route/rules regularly    syncPeriod: 5m    edgePodCIDR: 10.10.0.0/16    # namespace for fabedge resources    fabedgeNS: fabedge    debounceDuration: 5s  tunnels.yaml: |    # connector identity in certificate     id: C=CN, O=StrongSwan, CN=connector    # connector name    name: cloud-connector    ip: 10.22.45.30       # ip address of node, which runs connector       subnets:    - 10.233.0.0/17       # CIDR used by pod & service in the cloud cluster    nodeSubnets:    - 10.22.45.30/32      # IP address of all cloud cluster    - 10.22.45.31/32    - 10.22.45.32/32

⚠️注意：

CIDR：无类别域间路由（Classless Inter-Domain Routing、CIDR）是一个用于给用户分配 IP 地址以及在互联网上有效地路由 IP 数据包的对 IP 地址进行归类的方法。

edgePodCIDR：选择一个大的网段，每个边缘节点会从中分配一个小段，每个边缘 pod 会从这个小段分配一个 IP 地址，不能和云端 pod 或 service 的网段冲突。

ip：运行 connector 服务的节点的 IP 地址，确保边缘节点能 ping 通这个 ip。

root@edge1:~ # ping 10.22.45.30

subnets: 需要包含 service clusterIP CIDR 和 pod clusterIP CIDR

比如，service clusterIP CIDR 是 10.233.0.0/18，podClusterIPCIDR = 10.233.64.0/18 那么 subnets 是 10.233.0.0/17

获取 service clusterIP CIDR 和 pod clusterIP CIDR 的方法如下：

# service clusterIP CIDRroot@master:~# grep -rn "service-cluster-ip-range" /etc/kubernetes/manifests# pod clusterIP CIDRroot@master:~# calicoctl.sh get ipPool

nodeSubnets：需要添加所有的云端节点的 ip 地址

• 为 connector 创建 configmap

root@master:~# kubectl apply -f ~/fabedge/deploy/connector/cm.yaml

• 部署 connector

root@master:~# kubectl apply -f ~/fabedge/deploy/connector/deploy.yaml

• 修改 calico 配置

cidr 为前面分配的 edgePodCIDR，disabled 为 true

root@master:~# vi ~/fabedge/deploy/connector/ippool.yaml

apiVersion: projectcalico.org/v3kind: IPPoolmetadata:  name: fabedgespec:  blockSize: 26  cidr: 10.10.0.0/16  natOutgoing: false  disabled: true

# 不同环境，calico的命令可能会不同root@master:~# calicoctl.sh create --filename=/root/fabedge/deploy/connector/ippool.yamlroot@master:~# calicoctl.sh get IPPool --output yaml   # 确认pool创建成功​​# 如果提示没有calicoctl.sh文件，请执行以下指令root@master:~# export DATASTORE_TYPE=kubernetesroot@master:~# export KUBECONFIG=/etc/kubernetes/admin.confroot@master:~# calicoctl get ipPoolNAME           CIDR             SELECTOR   default-pool   10.231.64.0/18   all()      fabedge        10.10.0.0/16     all()

配置边缘节点

• 修改 edgecore 配置文件

root@edge1:~# vi /etc/kubeedge/config/edgecore.yaml

   a) 禁用 edgeMesh

edgeMesh:  enable: false

    b) 启用 CNI

edged:    enable: true    # 默认配置，如无必要，不要修改    cniBinDir: /opt/cni/bin    cniCacheDirs: /var/lib/cni/cache    cniConfDir: /etc/cni/net.d    # 这一行默认配置文件是没有的，得自己添加      networkPluginName: cni    networkPluginMTU: 1500

   c) 配置域名和 DNS

edged:    clusterDNS: "169.254.25.10"    clusterDomain: "root-cluster"

可以在云端执行如下操作获取相关信息

root@master:~# kubectl get cm nodelocaldns -n kube-system -o jsonpath="{.data.Corefile}"root-cluster:53 {...bind 169.254.25.10...}​root@master:~# grep -rn "cluster-name" /etc/kubernetes/manifests/kube-controller-manager.yaml​20:    - --cluster-name=root-cluster​# 本例中，domain为root-cluster,  dns为169.254.25.10

•  安装 CNI 插件

root@edge1:~# mkdir -p cni /opt/cni/bin /etc/cni/net.d /var/lib/cni/cacheroot@edge1:~# cd cniroot@edge1:~/cni# wget https://github.com/containernetworking/plugins/releases/download/v0.9.1/cni-plugins-linux-amd64-v0.9.1.tgzroot@edge1:~/cni# tar xvf cni-plugins-linux-amd64-v0.9.1.tgzroot@edge1:~/cni# cp bridge host-local loopback /opt/cni/bin

• 重启 edgecore

root@edge1:~# systemctl restart edgecore

• 确认边缘节点就绪

root@master:~# kubectl get node  NAME    STATUS   ROLES                   AGE    VERSION  edge1   Ready    agent,edge              125m   v1.19.3-kubeedge-v1.1.0  master  Ready    connector,master,node   135m   v1.19.7

部署 Operator

• 创建 Community CRD

root@master:~# kubectl apply -f ~/fabedge/deploy/crds

• 修改配置文件

按实际环境修改 edge-network-cidr

root@master:~# vi ~/fabedge/deploy/operator/fabedge-operator.yaml

apiVersion: apps/v1kind: Deploymentmetadata:  name: fabedge-operator  namespace: fabedge  labels:    app: fabedge-operatorspec:  replicas: 1  selector:    matchLabels:      app: fabedge-operator  template:    metadata:      labels:        app: fabedge-operator    spec:      containers:        - name: operator          image: fabedge/operator:latest          imagePullPolicy: IfNotPresent          args:            - -namespace=fabedge            - -edge-network-cidr=10.10.0.0/16     # edge pod使用的网络            - -agent-image=fabedge/agent                 - -strongswan-image=fabedge/strongswan              - -connector-config=connector-config            - -endpoint-id-format=C=CN, O=StrongSwan, CN={node}            - -v=5      hostNetwork: true      serviceAccountName: fabedge-operator

⚠️注意：

edge-network-cidr 为【部署 Connector】中“修改 connector 的配置”分配的 edgePodCIDR

• 创建 Operator

root@master:~# kubectl apply -f ~/fabedge/deploy/operator

确认服务正常启动

root@master:~# kubectl get po -n fabedgeNAME                               READY   STATUS    RESTARTS   AGEconnector-5947d5f66-hnfbv          2/2     Running   0          35mfabedge-agent-edge1                2/2     Running   0          22sfabedge-operator-dbc94c45c-r7n8g   1/1     Running   0          55s

关于 FabEdge

FabEdge 是一款基于 kubernetes 和 kubeedge 构建的开源网络方案，解决边缘计算场景下，容器网络配置管理复杂、网络割裂互不通信、缺少服务发现、缺少拓扑感知能力、无法提供就近访问等难题。

并且，Fabedge 支持弱网环境，如 4/5G，WiFi，LoRa 等；支持边缘节点动态 IP 地址，适用于物联网，车联网等场景。

Github：https://github.com/FabEdge/fabedge

官方网站：http://www.fabedge.io

官方邮箱：fabedge@beyondcent.com

微信群：打开“博云”公众号，点击菜单栏“扫码入群”

kubevirt是Red Hat开源的以容器方式运行虚拟机的项目，是基于kubernetes运行，利用k8s CRD为增加资源类型VirtualMachineInstance（VMI），使用CRD的方式是由于kubevirt对虚拟机的管理不局限于pod管理接口。通过CRD机制，kubevirt可以自定义额外的操作，来调整常规容器中不可用的行为。kubevirt可以使用容器的image registry去创建虚拟机并提供VM生命周期管理。

Kubevirt的架构

kubevirt以CRD的形式将VM管理接口接入到kubernetes中，通过一个pod去使用libvirtd管理VM的方式，实现pod与VM的一一对应，做到如同容器一般去管理虚拟机，并且做到与容器一样的资源管理、调度规划、这一层整体与企业IAAS关系不大，也方便企业的接入，统一纳管。

virt-api：kubevirt是以CRD形式去管理VM Pod，virt-api就是所有虚拟化操作的入口，这里面包括常规的CDR更新验证、以及console、vm start、stop等操作。

virt-controller：virt-controller会根据vmi CRD，生成对应的virt-launcher Pod，并且维护CRD的状态。与kubernetes api-server通讯监控VMI资源的创建删除等状态。

virt-handler：virt-handler会以deamonset形式部署在每一个节点上，负责监控节点上的每个虚拟机实例状态变化，一旦检测到状态的变化，会进行响应并且确保相应的操作能够达到所需（理想）的状态。virt-handler还会保持集群级别VMI Spec与相应libvirt域之间的同步；报告libvirt域状态和集群Spec的变化；调用以节点为中心的插件以满足VMI Spec定义的网络和存储要求。

virt-launcher：每个virt-launcher pod对应着一个VMI，kubelet只负责virt-launcher pod运行状态，不会去关心VMI创建情况。virt-handler会根据CRD参数配置去通知virt-launcher去使用本地的libvirtd实例来启动VMI，随着Pod的生命周期结束，virt-lanuncher也会去通知VMI去执行终止操作；其次在每个virt-launcher pod中还对应着一个libvirtd，virt-launcher通过libvirtd去管理VM的生命周期，这样做到去中心化，不再是以前的虚拟机那套做法，一个libvirtd去管理多个VM。

virtctl：virtctl是kubevirt自带类似kubectl的命令行工具，它是越过virt-launcher pod这一层去直接管理VM虚拟机，可以控制VM的start、stop、restart。

Kubevirt如何管理虚拟机？

虚拟机镜像制作与管理

虚拟机镜像采用容器镜像形式存放在镜像仓库中。创建原理如上图所示，将Linux发行版本的镜像文件存放到基础镜像的/disk目录内，镜像格式支持qcow2、raw、img。通过Dockerfile文件将虚拟机镜像制作成容器镜像，然后分别推送到不同的registry镜像仓库中。客户在创建虚拟机时，根据配置的优先级策略拉取registry中的虚拟机容器镜像，如果其中一台registry故障，会另一台健康的registry拉取镜像。

虚拟机生命周期管理

KubeVirt虚拟机生命周期管理主要分为以下几种状态：

• 虚拟机创建：创建VM对象，并同步创建DataVolume/PVC，从Harbor镜像仓库中拉取系统模板镜像拷贝至目标调度主机，通过调度、IP分配后生成VMI以及管理VM的Launcher Pod从而启动供业务使用的VM。
• 虚拟机运行：运行状态下的VM 可以进行控制台管理、快照备份/恢复、热迁移、磁盘热挂载/热删除等操作，此外还可以进行重启、下电操作，提高VM安全的同时解决业务存储空间需求和主机异常Hung等问题。
• 虚拟机关机：关机状态下的VM可以进行快照备份/恢复、冷迁移、CPU/MEM规格变更、重命名以及磁盘挂载等操作，同时可通过重新启动进入运行状态，也可删除进行资源回收。
• 虚拟机删除：对虚机资源进行回收，但VM所属的磁盘数据仍将保留、具备恢复条件。

虚拟机创建流程

虚拟机创建分为创建DataVolume和VMI两个流程：

1. 创建DataVolume后，CDI组件创建对应的PVC并且关联到合适的PV，然后通过临时Importer Pod拉取虚拟机容器镜像绑定到DataVolume生成的PV中，并且将镜像转换成disk.img文件存储在PV中供虚拟机使用。
2. 创建VMI后，等待disk.img转换成功，然后在对应的Node上启动Launcher Pod，并将CDI流程生成的PV挂载到Pod内，当做虚拟机启动的系统盘。Launcher根据VMI的定义生成定义虚拟机的XML文件，然后调用libvirt进程调用Qemu命令创建并且启动虚拟机。VMI会对Launcher Pod状态进行同步，反应VM运行的状态。

Kubevirt如何实现容器与虚拟机交互TBD

容器和虚拟机互通

• Virtual-Kubelet对应的Node会上报节点上Pod的Endpoint，假定Kubernetes集群和IaaS层平台部署在同一个二层网络下，则集群内容器Pod可以访问VM-Pod，但容器Pod对于VM-Pod不可见；
• 针对上一点可以通过Macvlan等网络插件，将容器-Pod，降维至二层网络上，实现容器-Pod和虚拟机互通，有一定硬件要求。

如何实现⼀套集群下虚拟机与容器的混合调度与资源隔离

• Virtual-Kubelet提供的是一个虚拟节点用来向Kubernetes上报Node对象和Pod的状态和资源情况，虚拟机资源和集群内节点资源完全隔离；
• 在引入Virtual-Kubelet的情况下，需要对Virtual-Kubelet节点配置Taint和Tolerations，保证容器-Pod和VM-Pod调度分离。

服务发现

Virtual-Kubelet，通过Provider实现的API将IaaS层VM信息抽象成对应Pod对象的信息的方式来上报Endpoints，可以通过给CR添加no selector Service，待VM-Pod拉起后补充address至对应的Service

Kubevirt适用场景

由于Kubervirt提供的成熟的虚拟化能力和性能，并且可以直接通过Kubernetes进行统一管理。所以Kubevirt适合在有PaaS层管理平台和Kubernetes集群环境的情况下，通过kubevirt中的单一控制平面简化了对虚拟机的管理，让用户无需关心IaaS层，即可轻松在集群内构建、部署出一台虚拟机进行使用。

如何搭建Kubevirt

Kubevirt安装

1. 前置条件

查看硬件是否支持虚拟化

如果虚拟化不可用，则需要手动开启软件仿真

2. 安装Kubevirt组件

直接操作以下命令进行安装

3. 检查实例是否正常运行

4. 启动相关特性

修改kubevirt-config configmap内的数据

5. 安装virtctl

安装kubevirt命令行工具

6. 安装CDI

CDI(containerized-data-importer) 是kubernetes的持久存储管理插件，帮助kubevirt构建磁盘镜像，可以将不同来源的数据源（url、container image、upload….）来填充pvc的能力。

获取最新版，进行安装

安装完毕后，会在cdi namespace下，启动cdi相关组件

至此，kubevirt安装完毕

创建虚拟机

1. 准备一个虚拟机镜像

通过dockerfile构建出一个虚拟机镜像

2. 创建一台VM

编辑好yaml文件，通过kubectl命令拉起一台vm

如今，各大企业都将技术研发中心定位于参与企业发展战略、重大的新产品、新技术的决策，是整个企业技术管理、决策的龙头和核心。而 DevOps 作为软件工程领域目前大家公认相对更好的一种工作方式和 IT 组织文化，近两年备受企业关注与尝试。

今天，就跟大家聊聊企业研发过程管理的6个痛点，和如何通过落地 DevOps 平台及解决方案处理这些问题的。

痛点1

需求开发过程协作难 

很多团队的协作模式仍然是传统的 CMM 类的思路，概括一下就是“重型文档、低频交流”。日常的工作组织形式则五花八门，并且有很多用户一开始其实并没有做到所谓标准的“瀑布”，或者“敏捷”。他们可能非常在意文档的交接，但又很难做到事无巨细的文档，甚至文档后补也是常事；可能有2-4周一个周期的迭代或者上线窗口，却未必能做到在约定周期内将内容交付；可能排到每个工程师手里的工作除了新功能开发，还会有很多缺陷修复或者其他各种工作，而这些工作又未必会被认可投入工时；还有不同项目的工作任务较之而来，让人难免出错，以至于可能有时候都会忘记自己曾经投入工时做的工作。

所以，如何帮助工程师和工程师主管清晰、有效地解决个人和团队工作排程问题是在需求开发协作过程中的第一个问题，并且这其实也是对项目组和工程师的一种保护。

解决方案   

通过落地 DevOps 平台及解决方案，可以以“工作项（需求/缺陷/任务等）”为管理对象，以“版本”、“迭代”为管理单元，以看板、甘特图等为工具，将团队协同工作快速组织起来，建立可视化的管理方式，并且与上游的业务需求、下右的代码等关联起来。

痛点2

研发测试过程缓慢 

管理者总是希望研发过程快一点，更快一点，希望尽快的交付业务价值。而研发团队此时便需要思考时间究竟要如何分配？哪部分花掉的时间是可以节省下来的？

对于一个生产级的代码工程（Project）来说，除了敲代码、思考、重构花掉的时间之外，其实有很大一部分是工程构建和测试时间。让我们把视角从某个工程师的身上转移到整个研发团队，如果每个人每天在工程构建和调试上花2个小时，那一个10人的小型团队一天的开销就是20小时，也就是超过2个工作日的时间，那如果周期放到一个月呢？

而现代化的软件开发，通过 DevOps 实践，可以将这部分开销大大降低。通过工具链的构建降低工程师的重复劳动时间，并自动化测试来快速回归并保证构建的质量基准。

解决方案 

通过落地 DevOps 平台及解决方案，大幅度减少团队花在工程构建、回归测试方面花费的时间。并且通过每日构建、特定分支合并构建等实践形式，避免在最终集成测试的时候才发现构建过程中的问题。

痛点3

代码管理混乱 

通过观察，有大量的研发型组织，在导入 DevOps 之前，甚至都没有一个组织级明确的代码分支管理策略。有的组织在使用 SVN 时，仅仅是把 SCM 工具用来打 Tag ；有的组织虽然已经开始使用 Git ，却没有利用好现代化 SCM 工具便捷强大的分支管理能力；还有的组织在使用 Git 时，分支间的合并关系混乱。

代码是软件研发的核心产出物，是软件制品资产的基础。很难想像，混乱的代码管理模式中隐含着怎样技术风险。

除了规范性本身的问题之外，我们经常还会想看某个版本到底有哪些需求/工作内容，这些内容又对应了哪些代码的变更。亦或某些代码的变更是对应了哪些需求或者哪个版本，这些都是在代码管理领域应该被关注的内容。

解决方案 

通过落地 DevOps 平台及解决方案，可以结合不同的 SCM 工具，指定组织级的代码分支管理策略，规范化代码管理流程并降低代码背后隐含的风险。

痛点4

手工应用发布 

国内很多用户的生产发布都是定期发布窗口，比如银行和运营商，一到周四或周五发版日，为了不影响业务，往往是深夜才开始发版，整个发布过程都是手工操作，是否能一次性成功，除了软件本身的质量外，全靠具体工程师是否能全神贯注，打起十二分精神来应对每一个操作，所以命令级的发布部署手册必不可少。

而有些大型行业软件服务厂商的解决方案是，给自己的复杂业务系统嵌入一个自研的小型发布系统，以降低自身的发布难度。而这对于甲方客户来说，就是银弹了吗？

你会发现可能一家银行的发布，不同的业务系统、厂商，会有不同的发布系统。嵌入自研的小型发布系统的结果很有可能就是为了解决一个问题，却造成了更多的问题。

解决方案 

通过落地 DevOps 平台及解决方案，可以建立统一的发布体系，并且灵活应对生产和非生产的发布场景。对于生产类发布场景，通过上线申请单、环境资源准备、发布流程编排等能力，代替原有人工发布的方式，降低相关工程师的操作风险与工作压力，将发布过程从“黑盒”变为“白盒”，可重复、可验证。

对于非生产类的发布场景，除了生产级的发布流程编排外，还可以通过流水线集成、容器云平台对接等方式，快速发布，减少等待时间，提速研发过程。

痛点5

研发过程改进缺乏抓手 

研发过程如何改进，是 CIO 和研发负责人永远关注的问题之一。软件行业经过多年的发展，其本身的复杂性和工程管理的的复杂性已经得到大家普遍认可。在找到银弹之前，我们需要一个抓手，通过改进和优化软件研发过程和流程，来提升研发的质量和效率。

在传统软件开发开发的场景中，这只能靠专家的知识积累和责任心。我们可能会看到一个团队中可能会有一个“高手”，每天疲于奔命在解决各种技术问题；也可能会看到组织成立了一个“架构部”，但架构部一定能解决具体项目组的难处吗？还是只是做口头的架构评审？

所以如何让专家们的知识传递到整个团队？如何将行业最佳实践嵌入到组织的软件研发过程当中？如何去观察我们到底有多少问题？如何判断从哪里开始改进？这些都是过程改进中的核心。

解决方案 

要想解开这些难题，一方面需要组织建设上的改进，另一方面很重要也可以很快看到效果的方法就是搭建工具链并建设 DevOps 平台。通过搭建工具链，让研发过程中的各种产出物数据（流水线、代码、制品、测试文件等）沉淀下来；而 DevOps 平台的建设，更是能在此基础上，将过程数据沉淀下来的同时，将沉积在各个工具中的数据整合、呈现出来，让“数据驱动研发过程改进”成为可能。

痛点6

组织级研发管理规范难以落地 

在推行组织级研发管理规定的时候，常常因为市场压力、计划时间限制、贵广执行难度等等各种错综复杂的原因而很难落地，最后导致研发管理规范成为一纸空文。不管是需求的分析流程/工具、代码的提交与合并策略，制品库的命名规范等等，研发的整个过程遍布了我们“希望规范而又难以规范”的情况。而在规范的另一面，研发团队也倍感焦虑，为什么在持续加班赶工的情况下组织仍然给我们增加额外的工作量？在规范落地过程中发现问题点并反馈时如何做到在真实准确的同时更容易被组织接受？

解决方案 

通过落地 DevOps 平台及解决方案，一方面可以将规范内嵌的系统和团队的日常工作中，另一方面还可以通过平台对研发过程和工具链过程数据的收集整合，将真实、清晰、有效的数据反馈给研发团队和组织管理者，通过持续的建设优化，形成可落地的、不断迭代发展的组织IT研发管理规范。

关于博云BeyondDevOps平台：

博云BeyondDevOps提供从“需求->开发->测试->发布->运维->运营”端到端的开发运营一体化平台解决方案，覆盖项目管理、研发管理、测试管理和运行管理的协同服务和研发工具支撑，将线下 IT 生产过程转变为线上高度自动化、可视化的 IT 生产线，提升产品研发效率，快速响应业务需求，保障工作质量，并通过度量分析、风险预判，持续提升 IT 运营能力。

作为率先通过中国信通院首批 DevOps 评估的厂商之一，博云 BeyondDevOps 平台获得 DevOps 应用开发域的最高级别——先进级认证。BeyondDevOps 的集成开发环境、代码托管、代码评审、编译构建、流水线、部署发布多项 DevOps 核心工具能力达到国内领先水平。

Rainbond 是云原生且易用的应用管理平台。云原生应用交付的最佳实践。专注于以应用为中心的理念，赋能企业搭建云原生开发云、云原生交付云。

对于企业： Rainbond 是开箱即用的云原生平台，借助 Rainbond 可以快速完成企业研发和交付体系的云原生转型。

对于开发者： 基于 Rainbond 开发、测试和运维企业业务应用，开箱即用的获得全方位的云原生技术能力。包括但不仅限于持续集成、服务治理、架构支撑、多维度应用观测、流量管理。

对于项目交付： 基于 Rainbond 搭建产品版本化管理体系，搭建标准化客户交付环境，使传统的交付流程可以自动化、简单化和可管理。

Rainbond 5.3.3 版本来了，本次发布的版本我们主要以用户实际需求为导向进行优化，在过去的一些实践中，我们发现，对于复杂的业务组件，部分资源的配置需要个性化配置，这就对我们平台使用的灵活性提出了更高的要求。因此 5.3.3 版本我们主要以配置的灵活性为主要迭代方向。

在一些开发场景中，用户机器可能是高内存型或高 CPU 型，此时用户机器资源往往得不到充分利用，因此现在我们提供了组件 CPU 设置的能力，用户可以根据自己需求个性化配置资源。其次，对于一些配置文件，用户除了配置文件相关内容外，也有配置其权限的需求，现在这些需求都可以得到满足。

主要功能点解读：

1. 支持实时查看 Rainbond 自身组件的状态和初始化进度

在该版本以前，我们在初始化 Rainbond 集群时，整体对用户是不可见的，相当于一个黑盒，用户出现问题，很难及时定位。现在我们在初始化 Rainbond 集群时，给出了集群的 pod 信息，用户可以通过可视化界面，直接了解到初始化集群需要多少组件，目前已经完成的组件数。还可点击组件，查看组件的事件信息。使用户能更直观的了解整个过程和快速定位问题。效果如下图所示：

2. 支持组件配置文件的权限设置

在之前的版本中，为某个组件挂载配置文件时，默认的权限为 0777 ，但是有些配置文件有权限要求，比如my.cnf，0777 会被忽略，因此在 5.3.3 版本中，支持为挂载的配置文件设置一个权限，用于解决该类问题。

3. 支持组件的CPU设置

在之前，我们只支持了组件的内存设置，CPU 通过算法得出。但这样有以下几个问题：

• 部分业务由于CPU资源分配过少，运行缓慢。出现问题甚至难以排查。

• 在部分开发环境中，用户想自己手动指定相应的 CPU ，也难以操作。

因此我们现在支持了自己手动设置组件的 CPU 和内存，且 CPU 和内存资源都可设置为不限制，给用户提供更灵活的使用方式。

4. 第三方组件的重构

为了逐步适配 OAM 应用规范，提升 Rainbond 的可扩展性。在之前发布的 5.3.1 版本中我们基于 OAM规范，重新实现了第三方组件类型，定义了 ThirdComponent 作为第一个 ComponentDefinition，并在产品中实现对ComponentDefinition 的基础管理机制。此次我们基于 ComponentDefinition 定义重新实现了第三方组件的静态配置和 API 配置实例类型。现在第三方组件已支持添加多个端口，并支持对应端口进行绑定。下面我对此次第三方组件的功能点做个简要说明。

假如现在你的第三方组件只开启了 80 端口，此时该组件有以下两个实例 10.10.10.10:80 ，10.10.10.11:5000

• 支持单端口映射到不同端口的endpoints

  对于第三方组件，只开通一个端口，添加多个实例且多个实例端口不同时，那么可以通过开通的端口轮询访问到该组件下的所有实例。

  参考上述前提，那么此时你访问第三方组件的 80 端口，实际是会轮询访问这两个实例 10.10.10.10:80 ，10.10.10.11:5000

• 添加多个端口，多个端口的绑定关系

  此时为第三方组件新建端口 5000 ，那么对应的端口将会与实例进行绑定，此时访问第三方组件的 80 端口，将只会访问到实例 10.10.10.10:80 ，访问 5000 端口，也只会访问到实例 10.10.10.11:5000。

5. 应用模版的变更

在 5.3.3 版本中，我们更改了应用模版的元数据模型，支持了更多组件属性的发布。如组件的 CPU 设置、组件特性、组件网关策略、配置文件权限的发布与安装等。其次，基于元数据模型的变更，我们在导出 RAM 规范的应用时，也支持了应用 logo 和版本信息的导出，现在，你可以更好的导入应用并获得该应用的版本信息。

6. 支持组件的容器日志可以单独查看

在以往的版本中，一个组件下有多个容器时，多个容器的日志均输出到日志页面，难以区分。在 5.3.3 版本中，这不再是问题，5.3.3 版本中支持单独查看各容器的日志，你只需在组件日志页面选择你需要查看的容器，即可快速获取到你关心的信息。

详细变更点：

新增功能

• 【安装】支持查询Ranbond组件的状态信息和安装进度；

• 【应用管理】支持网关访问策略的发布与安装；

• 【组件管理】支持配置文件设置文件权限；

• 【组件管理】支持设置组件和插件的CPU；

• 【组件管理】支持查看组件内各容器的日志；

• 【组件库管理】支持导入导出应用模版的logo和版本信息；

• 【第三方组件】支持第三方组件添加多个端口；

• 【第三方组件】支持单端口映射到不同端口的endpoints；

优化功能

• 【性能】缓存企业级统计数据，提升首页展示速度；

• 【存储】自动清理备份恢复和导入时产生的缓存数据；

• 【稳定性】升级底层ingress版本；

• 【日志】优化allinone部署的控制台日志持续输出无法连接redis的问题；

• 【日志】优化导入大体积模版时rbd-chaos的日志提示；

BUG 修复

• 【安装】修复集群安装驱动服务崩溃的问题；

• 【安装】修复同名称集群,重新安装失败的问题；

• 【安装】修复初始化Rainbond集群操作未实现幂等的问题；

• 【网关】修复两条相同网关策略导致网关报错的问题；

• 【组件库管理】修复应用模版release状态展示错误的问题；

• 【资源统计】修复团队使用资源统计中磁盘使用量统计错误的问题；

• 【应用管理】修复应用治理模式切换错误提示的问题；

• 【应用管理】修复恢复时删除原应用下组件导致恢复失败的问题；

• 【应用管理】修复升级时未变更组件仍然进行了滚动更新的问题；

• 【应用管理】修复升级时只发布部分组件，导致升级后依赖丢失的问题；

• 【组件管理】修复组件配置文件名称校验错误的问题；

• 【组件管理】修复第三方组件实例数与初始化状态错误的问题；

云原生应用理念经过几年的落地实践已经得到企业市场的广泛认可，云原生应用更是成为企业数字化转型的必选项。基于云原生技术架构衍生的产品和工具，已经逐渐应用在开发者的日常工作当中。

近日，全球最具影响力的咨询机构Forrester联合阿里云发布《云原生开发者洞察白皮书》，JFrog中国首席架构师王青受邀参与该白皮书的编写。Forrester首次定义云原生时代开发者的能力模型，助力开发者拥抱云原生技术，实现开发者自身的转型。

早在2020 年IDC发布的报告中，曾提到在未来的 3-5 年，软件制品的数量会越来越多，到 2025 年，全球会出现520M 个应用，超过 60%的企业软件版本的部署频率为 1 天，甚至更短。软件发布的种类也越来越多，Go、Maven、Docker、NPM 等类型的制品会不断的从研发中心构建出来，并推送到云环境进行部署。同时，由于开发者不熟悉云资源的使用，且依赖大量的开源软件，导致开发的软件遇到了部署难、安全管控难、传输慢等常见问题。

这样就给开发者带来一个新的挑战：开发者如何将制品快速的分发到各个云原生环境进行快速、安全的发布？我认为开发者需要从以下几个方面做出改变。

一、软件供应链安全可控

在云原生环境下，你的服务极有可能是对互联网开发服务的，由于开发者使用的依赖包往往来自于互联网公有仓库，这就使得使用了开源软件的应用容易被黑客攻击。大家可以尝试在云环境中安装一个 Jenkins 直接对外提供服务，用不了几天就会被黑客攻击，并且在你不知情的情况下种下木马，去挖矿或者执行其他任务。

我们应该如何解决？

整个部署过程必须使用自动化工具来保障软件供应链的安全可控，应当通过自动化工具自动生成软件物料依赖清单 SBOM，并实时扫描依赖包的漏洞风险和 License 合规性。开发者应该使用实时的开源组件分析工具，进行实时的 SAST 静态应用安全扫描，在开发阶段把已知的安全漏洞扫描出来，并根据优先级进行修复。参考以下操作流程：

1.1 使用Sonarlint 进行静态代码扫描，实时修复漏洞

1.2 在IDE中安装JFrog插件，实现开源组件漏洞和License的合规性检查

通过对开源软件供应链的扫描，实现对依赖的管控。

在构建过程中，自动收集软件物料清单 SBOM 如下：

通过自动的依赖清单收集，能够清晰的定义软件版本的依赖信息，以及依赖组件的漏洞扫描信息和 License 合规性信息。

二、面向云资源的部署

开发者在云原生环境下，想要实现应用的部署，必须熟悉云资源的类型，从而将云资源的字段从应用配置中抽取出来，这样才能实现一次构建，处处运行。以 Kubernetes 应用开发为例，开发者之前在本地配置的数据库、存储、端口等配置都需要抽取出来，定义成 YAML 文件的变量，抽象成 Helm Chart，这样开发者在本地开发配置的程序内，不做任何修改，只通过修改应用的 Chart Values文件，即可实现云环境的适配。

三、 Docker镜像高效分发

当版本发布之后，需要具备快速、高效的将版本分发到多地数据中心、边缘节点、IOT 设备等能力，例如支持大文件分片分发，支持 Docker 镜像的 P2P 分发等能力。

Docker 镜像的P2P分发将成为大企业在云原生环境下的必备能力，通过 P2P 分发，能够极大的提升 Docker 镜像的下载速度，快速的将新功能部署在服务器上，更快的给用户带来价值。

云原生时代已经来临，在云原生的环境下，企业及开发者想要占据先机，快人一步，就必须实现流动式的软件版本发布，才能在发布频率越来越快的将来站稳脚跟，奋勇前进。

添加小助手微信：JFrogjiewachina，您将获得《云原生开发者洞察白皮书》