据 Github 2021 年度报告显示,目前 Github 用户数已超 7300 万,中国 Github 开发者 755万,开源吞噬世界的当下,越来越多中国开发者和企业积极参与开源建设。


有一位从事开源 10 多年的从业人员,戏称自己为未来希望成为三线城市艺术家,打造“田园程序猿的乌托邦”。抱着对开源的热情,为国内开发人员和 DevOps 人员提升开发、上线、运维的效率,建木团队研发并开源了“建木”。他就是九州云的联合创始人章津楠,为什么他这么说?“建木”具体是什么项目?


“建木”萌芽


“建木”是基于九州云多年来在项目上的思考与实践:


时间滑回 2015 年,九州云为征信中心研发测试云咨询和落地实践项目时,当时团队的设计方案是从底层基于 OpenStack 的IaaS私有云的构建,到上层基于 Jenkins 的CI/CD流水线,在实践的过程中体会到了 DevOps 的优美和不足,并开始从开发者视角来审视 DevOps,内心埋下自研“建木”的种子。


2018 年,九州云参与金融机构的自动化运维项目,通过从运维人员视角的思考来从业务的角度理解 DevOps 对运维人员的价值,更加理解金融领域对 DevOps 的述求和管理者视角——稳字当头的“敏捷”。“建木”种子在实践的土壤里默默潜伏,于 2020 年真正萌芽起来。


伴随云计算的快速发展,如何自动化运维和管理云 IT 设施成为企业新的技术挑战,随着九州云业务飞速迭代,九州云本身同样面临人员危机。通过对自身“能不能自己革自己的命”,让 DevOps 更简洁,自研工具并在其上搭建需求场景,将业务流程固化,提高运维效率,从而赋能开发、运维人员。2020 年底,“建木”应用而生。得益于九州云一直以来的开源经验,从诞生的第一天起,建木便决定以开源的形式回馈社区。


建木优势:简洁、流程配置可视化


传说中,“建木”是上古先民崇拜的一种圣树,是用作沟通天地人神的桥梁,伏羲、黄帝等均通过这梯子上下往来于人间天庭。《淮南子·墬形训》曰:“建木在都广,众帝所自上下。日中无景,呼而无响,盖天地之中也。”


因此建木团队希望“建木”成为开发人员、运维人员在不同业务场景下相互沟通的桥梁。建木以触发器、流程编排、任务分发等功能为平台核心,支持 SDK 管理、密钥管理、统一日志、统一存储、统一认证等服务,应用在 CI/CD、DevOps、自动化运维、多业务系统集成等场景中。目前建木已应用在九州云真实业务中。


从技术架构上,建木分为任务执行层、流转分发层、概念定义层、支持服务。


任务执行层:执行器管理和任务执行过程管理,目前建木项目会提供一些默认的执行器,社区的开发者也可以通过自身的需要扩展自己的执行器。后续建木项目也会提供一些更有意思的任务节点,现在以建木Hub的形式对外提供。


流转分发层:自研流程引擎,分发层根据触发器来触发流程的执行和执行过程中的分发策略的控制,来对所有的流程(或者 pipeline)的任务根据任务优先级、任务类型、执行器使用率等情况进行合理的分发和调度。


概念定义层:对任务通过流程的方式进行定义,考虑到在建木CI 场景中会比较多的采用pipeline 的形式出现,支持 pipeline 模式的定制。为了更加便于开发者使用,自定义了一整套以 YAML 为基础的 DSL,方便用 git 等版本管理工具对流程进行统一的版本管理,从而实现GitOps。


支持服务:包含自动化集成会使用的统一认证、秘钥管理、SDK 管理等基础支撑模块。


建木官网采用中国式的卷轴形式打开,官网介绍了配置即代码,提供声明式语法将流程代码化,通过代码库进行版本控制,快速实现幂等部署与故障恢复:


“建木”萌芽,聚木成林


建木项目流程配置可视化,让任务编排与执行状态一目了然:


“建木”萌芽,聚木成林


采访过程中快速演示了如何使用建木,通过简单在建木配置语句,就可在 IM 软件自动发布一条群消息。目前建木进入木兰开源社区孵化,并在 Gitee 上托管,感兴趣的同学可以下载使用:

jianmu(建木): 建木持续集成平台基于建木,致力于为国内开发者与DevOps人员提供极致用户体验,提升开发、上线、运维的效率,让软件用户专注于提供业务价值。
https://gitee.com/jianmu-dev 

 

未来发展


谈及后续发展推广,章津楠表示,一是以产品的方式在社区推广使用,二是坚持开源,让用户以简洁地方式打开,不断吸引和积累用户。


建木团队的愿景是希望建木像组成物质的原子、组成DNA的基因、组成数字字节那样成为IT服务的一个个积木,开发者或者软件使用者可以像乐高积木一样创造自己都为止惊叹的“艺术品”。让 更多 IT 从业人员从体力劳动解放出来,从而真正实现田园程序猿的乌托邦——写代码是一种创作。


通过建木项目我们发现,作为国内较早一批提供开放云边基础架构技术开发和服务的九州云,以“开源·赋能云边变革”为核心,今年对外推出 Skyline、建木等开源项目,同时积极参与OpenStack、StarlingX、Kubernetes、OpenNess以及EdgeGallery等开源社区建设,不断在云计算及边缘计算领域建立深厚的技术储备和开源贡献。

————————————————

版权声明:本文为CSDN博主「CSDN云计算」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。


关于九州云:
九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、爱立信等众多重量级客户。

“建木”萌芽,聚木成林

KubeSphere 团队走进九州云,建立深度社区合作关系


2021 年 11 月 18 日,KubeSphere 核心产品技术团队走进九州云北京研发中心所在的北京市上地研华科技大厦,与九州云在北京、上海两地的技术团队在产品、技术与社区合作等话题上进行了深入交流与探讨。会上,KubeSphere 产品负责人于爽介绍了 KubeSphere 产品当前的发展情况,KubeSphere 开源社区经理周鹏飞详细介绍了 KubeSphere 开源社区治理以及如何社区贡献,KubeSphere DevOps 负责人赵晓杰也初步介绍了 KubeSphere DevOps 后续的发展路线。


在双方团队交流中,九州云 CTO 龚永生老师也表达了九州云产研团队对参与 KubeSphere 社区贡献的期望,同时提出了九州云对 KubeSphere 项目相关的需求与社区治理方面的建议。


KubeSphere 团队走进九州云,建立深度社区合作关系

龚老师非常支持九州云产研团队参与 KubeSphere 开源贡献,并提出将在九州云为产研团队设立参与 KubeSphere 开源贡献的奖励。此外,龚老师对 KubeSphere 在容器安全与策略管理层面提出了相关需求,比如希望 KubeSphere 能够集成 Open Policy Agent 提供更丰富的安全管控策略以及对非 root 用户在使用和管理容器的安全最佳实践。在双方交流会上,龚老师还分享了自己参与 OpenStack 社区的一些经验和 OpenInfra 基金会的运作方式。

九州云研发总监吴文相对 KubeSphere 社区的组织架构、治理运作、参与方式、社区身份提出了多个问题,KubeSphere 开源社区经理周鹏飞对此进行了解答。目前 KubeSphere 社区设立了 TOC、User Group 和 Developer Group 的组织架构,社区为不同贡献程度的贡献者设立 Contributor、Member 和 Maintainer 的社区身份并发放证书和纪念周边奖励。KubeSphere 社区通过 SIG 例会的方式在社区进行公开探讨开发计划与需求,并且所有例会录屏回放可在 B 站进行回看。社区使用 Slack 和微信群进行开发相关的沟通,配合 GitHub issue、PR、文档的方式进行异步地协同,社区通常也会在例会中过一遍当前的 Issue 和 PR 的进展。

对于初次参与 KubeSphere 社区贡献的成员来说,通过阅读开发者文档、开发相关视频、社区例会和认领 “Good first issue” 的方式是比较容易快速上手的。对于有经验的贡献者来说,如果想给 KubeSphere 社区贡献一个较大的功能或改进,社区推荐的方式是先在 GitHub 或中文论坛提交 Proposal 与社区进行讨论后,再开始参与设计和开发。

事实上,九州云在此次交流之前就已经有 moweiwei、Hanamichi 等成员参与了 KubeSphere 社区的贡献,给 KubeSphere 后端主仓库、Console 以及 OpenFunction 项目提交过 Pull Request。九州云在开源领域已有近 9 年的深度投入与贡献,在 2018 年最新的 Rocky 发行版排名中,九州云在核心模块贡献跃居全球第二,中国第一,其中在容器部署 Kolla 项目、Freezer 项目等重量级项目上贡献全球第一。龚老师作为本次合作的主要牵头人,同时也是 OpenStack 社区网络项目 Tacker 负责人,担任 EdgeGallery 社区技术指导委员会(TSC)副主席。

欢迎九州云参加开源社区共建



此次交流后,双方也在开源社区的合作共建上达成了高度共识,KubeSphere 社区在会后也已经邀请九州云产研团队成员加入了贡献者大家庭,非常期待九州云深度参与 KubeSphere 社区。

KubeSphere 开源项目发起人周小四说:“保持 100% 的开源与开放是 KubeSphere 团队秉持的理念,通过开放的社区治理与协同开发,能够让更多的企业参与进来,更高效地开发和维护好一款在全球流行的开源软件,企业不用再重复造轮子”。

我们非常高兴看到国内的开源协作氛围变得更加开放和友好,在开源社区逐渐了涌现了很多像九州云这样的致力于深度践行开源贡献与协作的企业。当开源项目与社区的贡献者有来自多家企业的深度参与,保持社区的多元性和开放性,开源软件的迭代和竞争力才会具备“飞轮效应”,在全球产生更大的影响力。

关于九州云



浙江九州云信息科技有限公司(以下简称“九州云”)成立于 2012 年,是中国早期从事开放云边基础架构服务的专业公司,目前九州云员工近 300 人、业务拓展区域覆盖全国及亚太地区,在北京、上海、广州、重庆、西安、无锡等地均设立分支机构。

公司成立至今,九州云始终以“开源·赋能云边变革”为核心,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。在中心云/私有云侧,九州云可提供 IaaS 云、CaaS 云、多云管理平台 CMP、自动化运维平台 AutoOps、SD-WAN 等企业云完整解决方案;在边缘云侧,九州云可 提供 MEC MEP 协调器、边缘 UPF 网元、边缘轻量化 Edge-IaaS/CaaS 底座、 Edge-Dev 边缘开发者中心、Edge-MECM 边缘管理平台、Edge-Portal 边缘自助平台、边缘场馆/娱乐等的全方位边缘云解决方案。

关于KubeSphere



KubeSphere (https://kubesphere.io)是在 Kubernetes 之上构建的开源容器混合云,提供全栈的 IT 自动化运维的能力,简化企业的 DevOps 工作流。目前 KubeSphere 在全球已有超过 70w 次下载,总计 250 多位贡献者和 8.2k GitHub Star,并将 Fluentbit Operator 和 OpenELB 等项目捐给 Fluent 社区和 CNCF。

KubeSphere 目前已在 AWS、Azure、DigitalOcean 和 QingCloud 等各大公有云深度集成 Kubernetes 容器服务,被 Aqara 智能家居、爱立信、本来生活、东软、华云、新浪、新东方、三一重工、华夏银行、四川航空、国药集团、微众银行、杭州数跑科技、紫金保险、去哪儿网、中通、中国人民银行、中国银行、中国人保寿险、中国太平保险、中国移动、中国电信、天翼云、中移金科、Radore、ZaloPay 等海内外数千家企业采用。KubeSphere 提供了开发者友好的向导式操作界面和丰富的企业级功能,包括 Kubernetes 多云与多集群管理、 DevOps (CI/CD)、应用生命周期管理、边缘计算、微服务治理 (Service Mesh)、多租户管理、可观测性、存储与网络管理、GPU support 等功能,帮助企业快速构建一个强大和功能丰富的容器云平台。



关于九州云:
九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。

KubeSphere 团队走进九州云,建立深度社区合作关系

建木持续集成平台是基于建木自动化平台提供的国产开源CI/CD产品,致力于为国内开发者提供简单易用、方便快捷的开发体验,推广DevOps的最佳实践,填补国内开源软件供应链中缺失的一环。

建木持续集成平台v1.1.1现已发布


主要更新:修复若干已知bug,含下列issue
  • 事件桥接器删除无明确提示删除桥接器的名称
  • 中英文自宽导致删除按钮浮现时会挡住后面的省略号
  • 鼠标滑过节点时浮现的操作按钮会出现在其他节点上
  • 新增事件桥接器输入目标唯一标识,输入长度问题
  • condition后面的节点执行完毕之后,流程没有自动结束
  • 可删除运行中的项目,应禁止
建木持续集成平台v1.1.1发布
“建木”是上古先民崇拜的一种圣树,传说建木是沟通天地人神的桥梁。伏羲、黄帝等众帝都是通过这一神圣的梯子上下往来于人间天庭。《淮南子·墬形训》亦曰:“建木在都广,众帝所自上下。日中无景,呼而无响,盖天地之中也。”

为此项目命名为“建木”,希望本项目也可以成为不同业务场景下系统间相互沟通的桥梁。建木自动化平台以触发器、流程编排、任务分发等功能为平台核心,可以应用在各类使用场景下,包括但不限于,CI/CD、DevOps、自动化运维、多业务系统集成等场景。

所属社区
建木持续集成平台v1.1.1发布
“木兰开源社区”建立于2019年8月,是国家重点研发计划重点专项“云计算和大数据开源社区生态系统”的核心成果。旨在促进产学研用各方开源领域的交流,推动国家科技创新成果开源,加强企业、科教研单位和行业用户之间的沟通,推动开源成果转化落地,同时为各类开源项目提供中立托管,保证开源项目的持续发展不受第三方影响,通过更加开放的方式来打造和完善开源社区生态。

参与单位
建木持续集成平台v1.1.1发布
项⽬官⽹:https://jianmu.dev/
项⽬托管:https://gitee.com/jianmu-dev
项⽬文档:
https://docs.jianmu.dev/guide/index.html
在线体验:https://ci.jianmu.run/


关于九州云:
九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、爱立信等众多重量级客户。

建木持续集成平台v1.1.1发布

All Nexthop Lead to Destination – ECMP


OpenStack新版本Xena发布,Neutron也开放了新的网络特性ECMP。借此机会,我们将在本文中讨论讨论ECMP在网络使用中的作用及在Neutron中的实现。


一、啥是ECMP(Equal cost multi path)


技术周|条条大路通罗马- ECMP


网络环境中,条条大路通罗马。网络的起点和终点之间往往存在多条可行的路径。面对多条可行路径,小孩子才做选择题,成年的路由器则是全都要。这里全都要的方式就是通过ECMP。ECMP(等价多路径路由),即存在多条到达同一个目的地址的相等开销的路径。当设备支持等价路由时,发往该目的IP 或者目的网段的三层转发流量就可以通过不同的路径分担,实现网络链路的负载均衡,并在链路出现故障时,实现快速切换。当一帧帧报文来到路由器,站到了“人生”的十字路口,无论选择向左走还是选择向右走,它们终将在目标处相逢。

ECMP被多种路由协议支持,例如:OSPF、ISIS、EIGRP、BGP等。ECMP的常见路径选择策略也有如下几种:IP哈希,IP取模,平衡轮巡,带权轮询。在数据中心最为常见的Spine-Leaf架构的网络中,起点LEAF与终点LEAF通常经过ECMP将流量均衡至多个Spine交换机之上。


二、OpenStack中的ECMP


1、Neutron中ECMP的用途



目前,Neutron中的ECMP功能主要被设计用于支持Octavia下的“多主模式”。Octavia中用于执行负载均衡的多个amphora同时使用相同的VIP,通过在虚拟路由器下配置ECMP,针对该VIP的访问请求能被分发至多个active的amphora虚拟机。即多次负载均衡。第一次为路由器执行的ECMP负载均衡;第二次为amphora中LVS或haproxy执行的负载均衡。


2、Neutron中ECMP的实现



Neutron server 暴露了如下所示的一条API。通过调用该API实现对指定虚拟路由器的ECMP设置。

openstack router add route

–route destination=192.168.1.111/32,gateway=192.168.1.10

–route destination=192.168.1.111/32,gateway=192.168.1.20

–route destination=192.168.1.111/32,gateway=192.168.1.30 router-ecmp


Neutron L3 agent 则根据API下达的设置,通过下述命令,执行对虚拟路由器对应namespace的配置下发。

ip.route(‘replace’, dst='<destination_ip>’,multipath=[{“gateway”:”<nexthop1>”},{“gateway”:”<nexthop2>”},,{“gateway”:”<nexthop3>”}])


配合Octavia,最终实现的效果如下图所示。
 

技术周|条条大路通罗马- ECMP


3、当前使用方式存在的缺陷



当前的ECMP仍然需要基于报文的五元组的哈希。这意味着当其中某个“下一跳”失效,或从ECMP路由列表中移除时,所有的连接将被重新分布,进而导致TCP会话断开,发生雪崩现象。为了避免这样的缺陷,可以采用一致性哈希的方案,仅将故障链路的流量重新HASH到其他正常链路上,而非故障链路上的数据流则无需改变下一跳。
 

技术周|条条大路通罗马- ECMP


三、ECMP面临的一些问题


任何一项技术都是优点与缺点的统一。我们在享受ECMP带来的多路径负载均衡与链路备份同时,也不得不面对随之而来的一些问题。下面就列举ECMP使用过程中会对网络带来负面影响的数个缺陷。

1、不区分流类型,负载均衡效果不佳



ECMP的使用中,针对流量的负载均衡通常是基于流的形式,通常情况下单独的一条网络流的所有报文固定于运行于拓补中的一条固定网络路径流通。这种特性使得ECMP对流量大小比较均衡的网络环境拥有较好的负载均衡效果。而当网络如下图所示“大象流”与“老鼠流”明显时,基于流的ECMP并不能合理地将流量均衡至多个网络链路中。(相较于本文描述的逐流形式的ECMP,也存在逐包形式的ECMP。逐包可以提高ECMP的带宽利用率,使等价多路径路由分担更均匀,但存在数据包乱序的问题,需要确保流量接收的设备或终端支持报文乱序组包的功能。

技术周|条条大路通罗马- ECMP


2、对称网络下效果不理想



ECMP不感知全网拓补。如下图所示,运行ECMP的交换机A均匀的将流量分发给交换机B与交换C。然而由于交换机B与目标交换机F之间也存在多条链路,实际交换机B相较于交换机C可以承载更多的流量。交换机A均匀将流量分发至交换机BC上并未实现整网流量的最佳平衡状态。(基于端口权重的ECMP轮询方式可以缓解该问题)
 

技术周|条条大路通罗马- ECMP


3、拥塞无感,加重重载链路负担



与上一条缺陷类似,ECMP也不感知链路本身的负载状态。网络的复杂性导致实际网络链路的负载并不均衡。与路由器B相比,当路由器C工作负载较重,与路由器A链路带宽压力较大时,路由器A的ECMP仍然会将流量负载至B、C两条路径之上,全然不顾路径C已不堪重负。
 

技术周|条条大路通罗马- ECMP


4、部分设备对网络分片不友好



一些网络设备针对分片报文并不能顺利的进行ECMP相关的处理(华为6810)。


四、UCMP(Unequal cost multiple path)


既然存在等价多路径,必然存在非等价多路径。
 

技术周|条条大路通罗马- ECMP


根据前文描述的ECMP的部分缺陷,在等价链路上平均分配流量,就容易引起低速链路流量阻塞以及高速链路的带宽不能得到有效利用的问题。为了解决这个问题,用户可以在接口上配置非等价负载分担功能,这样等价链路可根据带宽不同而分担不同比例的流量,使负载分担更合理。例如,路由器两个出口,两路径,一个带宽是100M,一个是10M,如果部署是UCMP,则网络总带宽能达到100M+10M(任意比例) 的利用率,同样情况下使用ECMP,很有可能网络仅仅只能实现10M+10M的利用率。

关于九州云:
九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、爱立信等众多重量级客户。

技术周|条条大路通罗马- ECMP

技术周|0.03秒引发的网络“血案”


背景


用户Pike版OpenStack,Firewall drivers为Openvswitch。OpenStack内一租户网络下多台虚拟机中部署一个K8S集群,其中OpenStack下租户网络使用VxLAN,K8S集群采用Calico IPinIP网络方案。

技术周|0.03秒引发的网络“血案”

故障发生


用户报告K8S集群中Pod偶发网络不通。故障表现随机。并不固定在某些计算节点,也不固定于某些虚拟机,出现时间随机;用户在不变动任何OpenStack内虚拟机或网络资源的情况下,仅仅重建Pod,即恢复正常。而且出现网络中断的Pod原本处于正常通讯的状态。由于前两次用户通过重建Pod解决故障,并未留下现场尸体,排查并没有实质性进展。遂让用户下次出现同样故障时留下现场待排查根源后再恢复。PS:Random failure is quite a challenge.

故障现场


偶发的一次机会让我们再次遇到了这个事故现场。如下图显示位于不同计算节点中的Pod两两互Ping,仅其中一对Pod出现Ping不通的情况。
 

技术周|0.03秒引发的网络“血案”


通过对这两个Pod所在节点(下图T1、T2、P1、P1)进行抓包,初步断定了丢包点位于Com1的br-int上。Pod1发出的ICMP Response在br-int上不翼而飞。

技术周|0.03秒引发的网络“血案”


在Pod上持续Ping的同时,观察Com1节点br-int上流表定位到了这条流表的计数在同步增长。同步查看该OVS上的连接跟踪记录,可以明显看到VM1至VM2的协议号为4(即IPinIP报文)的流被标记为“mark=1”。基本可以确认VM1至VM2的IPinIP报文命中了这一条流表,导致Pod1与Pod2不通。

持续丢包的流表



cookie=0xcccccccccccccccc, duration=8725.531s, table=72, n_packets=16642, n_bytes=1668970, idle_age=0, priority=50,ct_mark=0x1,reg5=0x362 actions=drop

异常情况下的连接跟踪



4,orig=(src=192.168.0.33,dst=192.168.0.35,sport=0,dport=0),reply=(src=192.168.0.35,dst=192.168.0.33,sport=0,dport=0),zone=49,mark=1

故障分析


Pike版OpenStack br-int 上table 72中的流表项目与虚拟机对应的Port 出向Security Group有关(在Neutron代码中表72的宏定义名称即为rulers_egress_table)。接下来我们分析下为什么会出现这样的状况。

正常情况


正常情况下,通过IPinIP的ICMP Response报文会在表72中命中下述流表,进行正常的转发。

cookie=0xcccccccccccccccc, duration=8725.528s, table=72, n_packets=68693, n_bytes=12470448, idle_age=0, priority=77,ct_state=+est-rel-rpl,ip,reg5=0x362,nw_proto=4 actions=resubmit(,73)

异常情况


异常情况下,对应上述的流表依旧存在,却没有命中;而是命中了低优先级的
ct_mark=0x1,reg5=0x362 actions=drop。若要命中该流表,对应流量就必须先行命中ct_state=+est,ip,reg5=0x362
actions=ct(commit,zone=NXM_NX_REG6[0..15],exec(load:0x1->NXM_NX_CT_MARK[])),将连接跟踪表中的mark置为1(invalid)但这些状况在正常情况下不应出现。

cookie=0xcccccccccccccccc, duration=8725.528s, table=72, n_packets=68693, n_bytes=12470448, idle_age=0, priority=77,ct_state=+estrelrpl,ip,reg5=0x362,nw_proto=4 actions=resubmit(,73)
cookie=0xcccccccccccccccc, duration=8725.531s, table=72, n_packets=16642, n_bytes=1668970, idle_age=0, priority=50,ct_mark=0x1,reg5=0x362 actions=drop
cookie=0xcccccccccccccccc, duration=8725.531s, table=72, n_packets=2, n_bytes=156, idle_age=8725, priority=40,ct_state=+est,ip,reg5=0x362 actions=ct(commit,zone=NXM_NX_REG6[0..15],exec(load:0x1->NXM_NX_CT_MARK[]))

进一步观察流表(duration值),可以发现三条流表的生存周期有0.03s的轻微时间差,本应正确命中的流表比当前异常情况下命中的流表晚下发了0.03秒。至此可以得出一个初步的故障原因结论:0.03秒的流表下发时间差导致了当前流量的中断。具体分析如下图。

技术周|0.03秒引发的网络“血案”

仔细观察Neutron代码,也可以发现流表的下发流程之中,_initialize_tracked_egress,也发生在create_flows_from_rule_and_port之前。

def _initialize_tracked_egress(self, port):
    # Drop invalid packets
    self._add_flow(
        table=ovs_consts.RULES_EGRESS_TABLE,
        priority=50,
        ct_state=ovsfw_consts.OF_STATE_INVALID,
        actions=‘drop’
    )
    # Drop traffic for removed sg rules
    self._add_flow(
        table=ovs_consts.RULES_EGRESS_TABLE,
        priority=50,
        reg_port=port.ofport,
        ct_mark=ovsfw_consts.CT_MARK_INVALID,
        actions=‘drop’
    )
    ……
 
def add_flows_from_rules(self, port):
    self._initialize_tracked_ingress(port)
    self._initialize_tracked_egress(port)
    LOG.debug(‘Creating flow rules for port %s that is port %d in OVS’,
              port.id, port.ofport)
    for rule in self._create_rules_generator_for_port(port):
        # NOTE(toshii): A better version of merge_common_rules and
        # its friend should be applied here in order to avoid
        # overlapping flows.
        flows = rules.create_flows_from_rule_and_port(rule, port)
        LOG.debug(“RULGEN: Rules generated for flow %s are %s”,
                  rule, flows)
        for flow in flows:
            self._accept_flow(**flow)
 
    self._add_non_ip_conj_flows(port)
 
    self.conj_ip_manager.update_flows_for_vlan(port.vlan_tag)

安全组流表的更新通常发生在安全组更新之后,通过对上述流表生存周期与排查时间的反推,得到的安全组更新时间与OpenStack显示的用户更新安全组时间一致。根据用户的反馈,故障察觉时间也与安全组更新时间高度吻合。

最终结论


用户更新虚拟机的安全组,OVS agent更新安全组流表规则存在的时间差,好巧不巧,恰好在该短暂的时间差内,虚拟机中容器正在进行通信,导致流量被先行下发的流表错误标记为invalid,并记录了conntrack,后续流量进而持续被drop,无法继续正常通信。

关于九州云:
九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。

技术周|0.03秒引发的网络“血案”

近日,木兰开源社区TOC召开孵化项目审议会议,由9名专家共同对开源项目进⾏审议。其中,“建木”项目获得专家认可,以8票同意,1票弃权,无反对票通过木兰TOC答辩,满⾜进⼊孵化的条件。

建木由来

“建⽊”是上古先⺠崇拜的⼀种圣树。传说建⽊是沟通天地⼈神的桥梁。伏羲、⻩帝等众帝都是通过这⼀神圣的梯⼦ 上下往来于⼈间天庭。《淮南⼦·墬形训》亦⽈:“建⽊在都⼴,众帝所⾃上下。⽇中⽆景,呼⽽⽆响,盖天地之中也。”

自动化平台“建木”项目进入木兰开源社区孵化

为此项⽬取名为“建⽊”,希望本项⽬也可以成为不同业务场景下相互沟通的桥梁。建⽊⾃动化平台以触发器、流程编排、任务分发等功能为平台核心,可以⽤在各类使⽤场景下,包括但不限于,CI/CD、DevOps、⾃动化运维、多业务系统集成等使⽤场景。
 
“建⽊”整体软件分层如下图,主要分任务执⾏层、流转分发层、概念定义层,配合⽀撑的会有⼀个⽀持服务。

自动化平台“建木”项目进入木兰开源社区孵化

任务执⾏层主要考虑的是执行器管理和任务执行过程管理,目前建木项目会提供⼀些默认的执行器,社区的开发者 也可以通过⾃身的需要扩展自己的执⾏器。后续建木项目也会提供⼀些更有意识的执⾏器的形态,之后会以HUB的形式提供。 

流转分发层主要核心是流程引擎,整个分发层会根据触发器来触发流程的执⾏和执⾏过程中的分发策略的控制。通过这个层对所有的流程(或者pipeline)的任务根据任务优先级、任务类型、执⾏器使⽤率等情况进⾏合理的分发和调度。 

概念定义层主要是对任务通过流程的⽅式进⾏定义,考虑到在CI场景中会⽐较多的采⽤pipeline的形式出现,也⽀持 pipeline模式的定制。为了更加便于开发者使⽤,也⾃⼰定义了⼀整套以YAML为基础的DSL,⽅便⽤git等版本管理⼯具对流程进⾏统⼀的版本管理。

⽀持服务主要包含⾃动化集成会使⽤的统⼀认证、秘钥管理、SDK管理等基础⽀撑模块。

团队初心

建木项目发起人、九州云99Cloud联合创始人章津楠表示:“九州云源⾃于开源OpenStack社区,拥有开源的基因,也⼀直在共建开源社区。建⽊项⽬起源于2015年对某⾦融机构研发测试云项⽬在DevOps领域的思考和实践。在九州云“开源·赋能云边变⾰”的理想和共同⽬标指引下,重新对DevOps & OpsDev领域中共性、有价值的需求做了⼀次完整的梳理和重写,最终以“建⽊”开源项⽬的形态呈现。

建⽊项⽬进入⽊兰开源社区孵化仅仅是开始,未来属于国内具有开源精神的开发者们,期待⼤家的加⼊和不断的完善。”

自动化平台“建木”项目进入木兰开源社区孵化


项⽬官⽹:https://jianmu.dev/
项⽬托管:https://gitee.com/jianmu_dev
项⽬⽂档:https://docs.jianmu.dev/guide/index.html


关于“木兰开源社区”


“木兰开源社区”建立于2019年8月,是国家重点研发计划重点专项“云计算和大数据开源社区生态系统”的核心成果。旨在促进产学研用各方开源领域的交流,推动国家科技创新成果开源,加强企业、科教研单位和行业用户之间的沟通,推动开源成果转化落地,同时为各类开源项目提供中立托管,保证开源项目的持续发展不受第三方影响,通过更加开放的方式来打造和完善开源社区生态。


关于九州云:
九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。

自动化平台“建木”项目进入木兰开源社区孵化

Skyline:一个超好用的现代化 OpenStack 管理界面!

Skyline 是由 OpenStack 资深厂商九州云捐献给 OpenStack 社区的一款现代化的 OpenStack 管理界面(Dashboard),可以在 OpenStack 社区代码托管网站 OpenDev 上了解项目详情:
https://opendev.org/skyline/skyline-apiserver/src/branch/master/README-zh_CN.md

Skyline:一个超好用的现代化 OpenStack 管理界面!

OpenStack 自 2010 年问世以来,历经十多年的快速发展,其社区贡献者之多,参与厂商之广,影响之深远,可谓前不见古人,后难见来者。Horzion 是 OpenStack 社区默认推荐的 Dashboard 平台,但因其 UI 简陋、技术栈陈旧、性能和用户体验性较差等原因,被广大 OpenStack 用户诟病已久,可谓“天下苦 Horizon 久矣”。但遗憾的是,社区一直没能对 Horizon 进行整体技术升级,或者推出另一款更优秀和现代化的 Dashboard 供用户选择。今天我们很高兴看到,九州云捐献的 Skyline 项目填补了这一空白。

九州云是 OpenStack 黄金会员,自 2012 年开始参与 OpenStack 社区贡献,拥有多名 Core Developer 和 PTL,此次捐献的 Skyline 项目也另我们耳目一新。

1. 简单至上

Skyline 秉承了“Less is more”的设计哲学,保持“简单至上”,包括安装部署、用户操作、架构设计等方方面面。

1.1 简单上手:从一个 Docker 镜像开始


从官网可以看到,如果想试用 Skyline,可以从一个 Docker 镜像轻松开始。

Skyline:一个超好用的现代化 OpenStack 管理界面!

1.2 框架简明清晰


从 Skyline 官网可以看到,Skyline 分为两个模块:apiserver 和 web console。

Skyline:一个超好用的现代化 OpenStack 管理界面!

Skyline apiserver 模块基于 Python Fastapi 框架(一个高性能的 Python 异步 Web 框架)实现,相当于 Horizon API,但简单得多。Skyline apiserver 将绝大多数 OpenStack API 直接透传给 OpenStack endpoints,而不像 Horizon API 一样增加适配层。这样一来,我们就可以轻松地从浏览器的开发者工具中看到绝大多数的 OpenStack API 请求被直接发送到 OpenStack endpoints,请求和返回信息都会非常直观,这样就大大降低了系统出错时 Trouble Shooting 的难度。

Skyline console 是一个 JavaScript React 纯前端框架,不包含 Node.js,完全运行在浏览器上,非常轻量,且保持无状态。

Skyline 支持扩展,可以支持诸如计费、监控、计划任务等增值服务。

Skyline:一个超好用的现代化 OpenStack 管理界面!

2. 功能强大


2.1 覆盖了 IaaS 云平台的几乎所有功能


得益于九州云多年来深耕 OpenStack 的技术和客户需求经验积累,Skyline 从捐献之初其功能就已经非常完整,除了对计算、存储、网络的虚拟化支持完备之外,对于安全中心、计费分析、运维管理、Heat 编排、监控告警也有了很全面的支持(部分模块需要企业扩展包支持)。

Skyline:一个超好用的现代化 OpenStack 管理界面!

在管理界面上,Skyline 也覆盖了所有管理员需要的几乎所有功能模块,包括 workflow(需要企业扩展包支持)和全局设置等。

Skyline:一个超好用的现代化 OpenStack 管理界面!

2.2 在细节上更懂你


Skyline 界面在很多细节颇具匠心,令人赞叹。

比如虚拟机详情页中,我们可以直观地看到 VM 的所有信息,包括 USB 和 GPU 信息。

Skyline:一个超好用的现代化 OpenStack 管理界面!

Skyline:一个超好用的现代化 OpenStack 管理界面!

在网络模块中,不仅包含了 VPN / 负载均衡 / QoS / 虚拟网卡,还以更清晰的 topo 展示了网络。

Skyline:一个超好用的现代化 OpenStack 管理界面!

在个人中心,可以总览该用户相关的项目、工单、和审批流程。

Skyline:一个超好用的现代化 OpenStack 管理界面!


3. Skyline的发展动向

Skyline 还在快速成长中,预计 2021 年国庆前会完成与社区 Zuul CICD / DevStack / Kolla 等工具和项目的融合,届时 Skyline 会更稳定可靠,其部署安装也会更方便快捷。
Skyline 开发团队与 Horizon 项目开发者的合作讨论也在同步进行中,我们希望看到尽快看到社区开发团队能精诚合作,合力打造出优秀的 OpenStack Dashboard 项目。

4. 小结

Skyline 是九州云捐献到社区的诚意和匠心之作,正如其官网所述:“Skyline 的吉祥物是九色鹿。九色鹿源自于敦煌壁画《九色鹿本生》,其寓意是佛理因果和知恩图报,这与九州云自创办以来秉持的拥抱和反馈社区理念一致。我们也希望 Skyline 像九色鹿一样,轻巧、优雅,而又能力强大,为 OpenStack 社区和用户提供更优质的 Dashboard。”

我们很高兴看到国内的云计算企业开始向社区回馈贡献高质量的项目,希望这个项目能茁壮成长,也希望看到更多的优秀开源项目不断涌现出来。

关于九州云:
九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。
Skyline:一个超好用的现代化 OpenStack 管理界面!

技术周|软件架构设计之道

大家有没有经历过这些场景,我们选用了一些看似很酷的技术,但上线后结果并不理想,技术人员总是加班去解决一系列技术问题,虽然总是再加班,但解决的都是业务无关的问题。又或者采用了看着很高大上的技术去处理并发但系统上线后发现并没有那么大的业务量(杀鸡用了牛刀),这些对企业来说都是浪费。

第一种浪费来自于技术层面的BUG,技术是首先是为支撑业务的,企业应为开发出的业务买单,而非为没有价值的BUG买单。第二种浪费是过度设计,通常是由于技术架构与业务架构、组织架构不匹配所导致,这两种浪费问题在我们日常软件开发中经常出现。

在我最近几年做架构设计相关的工作中,处理的业务系统包括及其复杂订单调度系统、业务规则多变的企业级管理平台,以及对并发和性能要求较高的收单系统,期间遇到了各种各样的架构设计问题,我不断思考有没有一种方法可以规避上述提到的两种浪费问题。

今天我分享下相关的经验,以便让大家在实际软件架构设计过程中有所收获,当然软件系统的好坏不仅仅与软件架构设计有关,通常还和软件研发管理,市场反馈等方面息息相关、但此文中我们只讨论软件架构设计这个变量。

一、软件架构的本质与目的


软件架构一词在每个人心中都有自己的定义,维基百科的定义是“软件架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之间的关系,组件特性以及组件间关系的特性”。简单来说软件架构工作内容其实就是设计软件系统组件与组件(组件在这里是个统称,又或者是系统与系统,系统与模块)之间关系,为什么要设计组件与组件之间的关系呢,这就需要引出另外一个概念——软件架构的本质。

我们在日常软件研发过程中,会遇到各种各样的问题,比如梳理服务之间调用的关系,处理各种程序和中间件异常等,所以我们要通过一些手段尽量提前去规避这些问题,而软件架构就是解决这些问题的设计手段,所以软件架构本质就是为了解决软件开发过程遇到的各种各样复杂的问题,这些复杂的问题多种多样,总体上我认为可以分为两类,业务问题和技术问题。

如果只是为了解决业务或技术问题那就相对简单了,只选用高大上的技术或者我们完全基于需求分析人员的要求做开发就可以了,但软件架构设计的难点在于要在各种方案中去折中考虑,比如成本,研发人员数量,数据规模,性能等,而权衡的标准就是看能否快速高质量交付软件系统。这就引出了软件架构设计的目的——高质量的快速交付软件系统,为公司与客户实现降本增效。所以我们得出一个结论:技术是无法脱离业务孤立存在的,技术首先是支撑业务发展,要么为公司赚钱要么为公司省钱。下面我们就围绕软件开发的目的和本质来讨论如何解决业务问题与技术问题。

二、业务问题


软件架构设计中遇到的业务问题不只是要梳理复杂的业务规则或者画业务流程图,而是如何正确的定义业务问题,既客户真正的问题是什么,而理解业务往往是最容易忽略的点,业务不仅仅是需求人员或产品人员考虑的问题,协助需求人员对业务的梳理和抽象也是架构师的职责之一。业务问题往往比技术问题更加优先去解决,我们经常听到一句话“不基于业务场景去做架构设计都是耍流氓”。说的也是同样的道理,不理解业务我认为是导致架构设计混乱的主要原因之一,业务不定义清楚前期只能先靠程序员去coding, 后期出问题后再通过各种程序的技巧去规避这些业务问题,久而久之我们陷入加班填坑的状态,系统会慢慢演化为一个大泥球,最终崩塌掉。

举一个典型的例子,我们的业务人员希望在原有平台上增加一个数据分析系统,这样就可方便导出数据报表。某研发的同事负责设计了一套数据分析架构,考虑以后的扩展性引入了Flink,Kafka等等大数据相关技术,预估需要两个研发人员,4周的时间可以完成第一个MVP版本。技术上看起来比较酷,也解决了业务上的问题,但答案真的是这样吗?

 经过我们再次与业务人员再次沟通,其实业务人员只是想了解几个关键业务指标来监控日常订单的走势,对于其他业务指标并不是很关心。所以用4周时间建立一个大数据平台完全没有必要,最终我给出的方案是每天以邮件形式发送EXCEl格式的指标数据,预计投入1名研发,三天后可上线。显然第二个方案的交付速度更快,成本更低。所以对业务的理解深度不同,我们的架构方式也会不一样。

康威定律指出“组织沟通方式会通过系统设计表达出来”。组织架构也隐藏了我们对业务能力的划分,软件架构设计如果是逆康威定律那么导致的问题是业务架构与组织架构不匹配,最终也就无法交付出符合业务的系统。

也许一些做交付或者外包行业的同学会反对,因为我们不对客户“吹”,客户不会跟我们签合同,或者为了后期的维护费要不断给客户“挖技术坑”,但其实客户只要找一个专业的架构师去评审下就知道问题所在,相信我客户一定会这么做的,结果也一定是一锤子买卖,这也是国内做交付的企业被大家当成外包的原因之一。其实解决客户问题比挖技术坑更难,因为“同理心”的转变是反人性的。

软件设计过程中,如果不去理解业务,我们只能算是倒腾各种技术方案的架构师,所谓的“降本增效”就变得毫无意义,只能是满足了自己对技术快乐的追求,所以理解真正的业务问题是软件架构设计的第一优先级。

三、技术问题


只理解业务我们只能是一个业务专家,但架构师首先是一名优秀的软件开发工程师,需要具备极强的落地能力以及指导他人落地的能力,在我看来,“纸上谈兵的架构都是耍流氓。”所以深入理解各个技术应对的业务场景至关重要,我建议从以下四个方面考虑技术问题。

1、高可用


业务上是否具备高可用的需求,比如服务宕机后是否要有自愈能力,很多系统根本是不需要自愈能力的,只是出问题人工修复即可,这种情况下我们完全可以单机部署,只需要做好监控就好。

2、高性能


我们要理清业务的并发数是多少,用户可接受的相应延时有多大,如果只是在线人员为10个的系统,用微服务架构的意义在哪呢?

3、高扩展性


一般我建议考虑半年到一年内架构扩展性即可,我们可与业务人员沟通未来一年内业务增长量,比如只是临时用的系统,我们不必考虑任何扩展性,以最快的速度让系统上线。

4、其他


除了要考虑高性能、高可用、高扩展,我建议技术选型时还要根据CAP理论以及BASE理论去做技术选型,比如分布式锁的技术选型,要明白这个业务是AP场景还是CP场景,如果是CP场景就选ETCD分布式锁或Zookeeper分布式锁,如果是AP场景就行Redis分布式锁。

四、关于功利主义架构


业界不少架构师总结出了很多优秀的架构设计原则帮我们去做技术方案之间的权衡,比如“合适原则”,“简单原则”,“演化原则”等。不同的公司对这些原则的侧重点可能不同,初创公司可能是迭代业务为准,成熟型公司考虑的是1年内的业务扩展性以及稳定性,有没有一个通用的原则去满足不同公司阶段的场景呢,我认为是“基于功利主义去做架构设计”。

功利主义强调实际功效或利益去做决策,如果一个技术方案成本非常低,又能支撑业务发展,这就是一个好的技术选型。这样我们就可以把浪费在修复BUG上的时间转为做去技术创新,满足我们作为一名技术人员对技术理想的追求。
 
通过以上内容我们了解到软件架构设计的思想,但实践中有没有一套方法论或流程指导我们呢,答案肯定有,目前业界比较火的方式是使用DDD(领域驱动)的方式去做架构设计,DDD很好解决了业务定义问题,因为我们最终建立出的领域模型一定是与业务人员深入沟通的结果(比如采用事件风暴的方式),而非程序员的想象。

但要实施DDD需要团队成员每个人对DDD非常熟悉,单单是理解领域,仓储,事件,聚合等等这些概念就非常费劲了,所以DDD的落地并不简单。这又回到了软件架构设计的目的“降本增效”上,我们不必追求宗教式的DDD,所以我结合DDD的思想,总结出了一套架构设计过程,你可根据自己的项目对这个架构设计过程做删减。

五、架构设计过程


1、业务目标定义


我们可以拿张白纸,在上面写出如下问题的答案:

  • 1)客户在不用这个功能之前是怎么解决这些问题的?
  • 2)客户增加这个功能除了要解决问题1)还要解决哪些问题
  • 3)如果不能写出以上两个问题的答案,请询问相关业务人员。

2、业务模型抽象


  • 第一步我们要和产品经理或需求分析师一起建立业务模型。和DDD类似,我们可以采用将大的问题分解为若干子问题的方式,比如我们要向客户提供一个私有云的云计算解决方案,我们可以将整个方案分解为云计算管理平台(CMP),ISSA服务,PAAS服务,其中CMP可以继续分解为统一监控子系统,统一服务子,统一运营子系统。统一服务子系统内部就拆解为目录模块,自动化运维模块。注意这里拆解到模块级别就已经足够。这样我们就得到了整个业务功能的架构图。

  • 第二步开始梳理各系统之间模块之间的依赖关系,顺着数据流动过程画出模块之间关系依赖图。这样我们就将一个复杂的问题分解成为了一个个由简单模块组成的问题。

  • 第三步我们再次对每个模块再次进行分解,梳理模块内部的类之间的关系,以及类内部的行为,此时我们得到的是类似于UML类图。

经过以上分析我们得到了一个业务的全景图,系统之间关系图,模块关系图,模块内部逻辑图,由大到小,层层细化。

3、技术方案设计


根据步骤2的我们得出了具体的业务模型,接下来就是技术实现,我们可以采用DDD的分层架构,也可采用传统三层架构,对于DDD不熟悉的团队我建议采用传统三架构,采用失血模型实现业务,也就是所有的业务聚焦到service层。

此时我们还会面临架构风格的选择,比如单体还是微服务,对于小规模团队我建议还是单体优先或者分布式单体优先。

4、实施路线


架构最终是需要落地,所以我们还要制定具体实施的方式,对于一些大型的系统架构,需要分阶段交付,每一期最好可独立交付,想想我们国家的航天工程都是分好几期进行的。

六、结尾


由于篇幅有限只能写到这了,以上描述的架构相关的问题只是软件架构设计过程中的冰山一角,软件架构设计是一个综合类学科,包括了计算机科学,业务分析,哲学等多个领域。每个阶段我们对其认识也会不一样,这就需要我们不断学习,不断总结,一起做个终身成长的架构师吧。

技术周|软件架构设计之道

技术周|软件架构设计之道

关于九州云:

九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。

技术周|软件架构设计之道

点击原文,了解更多

技术周|软件架构设计之道
第23版:OpenStack Wallaby已上线!

OpenStack社区正式发布第23个版本 – Wallaby, OpenStack专注于开源基础设施软件的广泛开发与部署,作为全球三大活跃的开源项目之一(包括Linux kernel与Chromium),始终注重激发全球社区活力,提升社区开发者的参与度。
 
最新版Wallaby增强了安全性能,实现了与其他开源技术的进一步集成,进而强化了开源基础设施在云原生领域的应用。来自45个国家140家组织/机构的800多位贡献者所提交的17,000代码修改已成功合并至Wallaby版本。
 
OpenStack Wallaby版本现已上线!欢迎体验!
https://www.openstack.org/software/wallaby/
 

Wallaby版本要点:



除广泛改进OpenStack内核的稳定性与可靠性,提升项目集成功能的灵活性外,Wallaby版本还强化了安全性能,包括改进回退权限及Ironic、Glance及Manila组件中基于角色的访问控制(RBAC)权限,在该版本的开发周期中,社区重点关注将RBAC策略文件格式由JSON迁移至YAML。此外,Ironic还扩展了UEFI(统一可扩展固件接口)的功能,包括NVMe的安全擦除。
 

Wallaby版本的其他特性:



  • 数个项目团队通过强化对其他开源项目的支持,将OpenStack作为开源集成引擎持续进行开发:Kolla(可用于生产实践的容器化部署工具)添加了对Prometheus version 2的支持,Magnum(容器编排服务引擎,可提供统一API)同步了Kubernetes、containerd的更新版,Cinder(块存储服务)添加了对Ceph后端驱动程序Ceph iSCSI的支持。

  • Tacker(NFV编排)添加了与ETSI NFV所定义的标准一致的新功能,包括增加了可用于虚拟网络功能(VNF)扩展、更新及回滚操作的APIs,并可为ETSI NFV中的订阅和通知提供基本的VNF生命周期管理支持。

  • Nova(计算资源配置)与Cyborg(加速器管理)持续集成,新功能使用户可释放/取消释放增强实例、附带Cyborg加速器的Nova实例。

  • Cinder(块存储)添加了新的后端驱动程序,多个驱动程序添加了对不在驱动功能范围内的某些功能的支持,在本次开发周期中,恢复快照及后端QoS功能尤其流行。

  • 运营商可通过Neutron将网络端口中的固定IP地址路由到外部世界,而不受IPv4地址范围的限制。
 

了解更多版本详情:



https://releases.openstack.org/wallaby/highlights.html

Kendall Nelson,开源基础设施基金会OpenStack社区上游开发倡导者表示:“OpenStack已经发布至第23版,很开心这个全球性的社区正持续成长且充满活力,不断为OpenStack项目进行贡献。OpenStack社区一直是全球最活跃的三大开源社区之一,OpenStack Wallaby版本的发布展示了成功的社区协作模式如何保持软件的茁壮成长与高效开发,持续推动创新,为新兴用例提供技术支持,并实现跨项目与平台间的交互操作。”
 
开源基础设施的演进

OpenStack于10年前率先提出开源基础设施理念,并逐步成为开源基础设施即服务(IaaS)的事实标准。近年来,人工智能、机器学习、边缘计算及物联网等领域涌现出众多新的需求,推动OpenStack项目为新的芯片架构及裸金属的自动化扩展等提供支持,实现了与众多开源组件的集成。如今,OpenStack为全球75个公有云数据中心以及上千个私有云的运行提供技术支持,整体部署规模逾1500万计算核心,OpenStack基础设施平台适用于裸金属、虚拟机(VMs)、图形处理单元(GPUs)及容器等多种架构的部署。
 
线上项目小组集会(PTG)

开源基础设施基金会将于4月19-23日举行线上项目小组集会,基金会统一安排活动时间及地点,并提供必要的活动设施,让那些为OSF项目(包括代码提交、文档生产、运维人员或用户等)做贡献的各技术团队成员进行高效协作与交流,推动基金会各项目的发展。PTG对各项目下一个软件版本的开发至关重要,各小组成员不仅会讨论如何改进软件的核心功能,还会开展跨项目协作,解决复杂问题。运营商、开发人员和其他活跃的贡献者将讨论团队在未来几个月的优先事项,以及如何高效实现各项目小组的目标,建立互信互助关系,最终达成统一意见,并按照既定计划协作完成各项工作任务。如需注册参会或了解本次项目小组集会详情,请访问:openstack.org/ptg。
 
关于OpenStack®

OpenStack是唯一可在单一网络中提供APIs来编排裸机、虚拟机及容器资源的开源集成引擎,该项目背靠全球社区的支持,来自188个国家的100, 000多名社区成员进行技术协作与创新,与行业伙伴共同构建开源生态,为全球公有云和私有云平台的运行提供技术支持,进而实现软件开发的成本节约、可控和可移植性。
 
访问OpenStack官网,了解更多详情:www.openstack.org
 
关于开源基础设施基金会(OpenInfra Foundation)

开源基础设施基金会致力于构建多样化的开源社区,推进开源基础设施软件在实际生产中的应用。在全球188个国家/地区100,000余名社区成员的支持下,OIF托管了多个开源项目和实践社区,涉及人工智能、容器云原生应用、边缘计算及数据中心等基础设施领域。欢迎加入开源基础设施基金会!www.openinfra.dev

第23版:OpenStack Wallaby已上线!

九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。


EdgeGallery V1.1 (Dove Release)版本正式发布!

新版本发布


感谢社区伙伴们的共同努力与贡献,
EdgeGallery踏入新的征程。
2021年4月13日,社区正式发布V1.1 Dove版本。
于文末获取D版本下载链接
点击视频40S看完EdgeGallery1.1版本新特性。




新版本8大特性,支持5G MEC开源社区全方位提升技术水准、生态环境、运营能力、安全优化。一起来看看新版本具有哪些新优势?


EdgeGallery V1.1 (Dove Release)版本正式发布!



EdgeGallery社区仍在5G MEC的开源建设之路上日夜兼程,迭代不辍。期待你的关注与加入。

V1.1版本(Dove Release)详细内容请于ReleaseNote查阅:

https://gitee.com/edgegallery/docs/blob/master/Release%20Notes/EdgeGallery_RN_zh.md

V1.1版本(Dove Release)下载地址:

X86:
https://edgegallery.obs.cn-east-3.myhuaweicloud.com/releases/v1.1/x86/EdgeGallery-v1.1-all-x86.tar.gz

ARM:

https://edgegallery.obs.cn-east-3.myhuaweicloud.com/releases/v1.1/arm64/EdgeGallery-v1.1-all-arm64.tar.gz



EdgeGallery V1.1 (Dove Release)版本正式发布!

社区成员寄语

华为首席开源联络官,EdgeGallery社区董事会主席任旭东:经过3个月的努力,社区又一次发布了新版本。此版本在跨平台支持,AI能力增强,应用生态,以及Edge Native架构上都有了很大进步。希望借助此版本,能在更多项目中协助应用集成和落地部署,开展更多的商用实践。

九州云联合创始人、副总裁,EdgeGallery社区董事李开EdgeGallery从C(chocolate)版本的“巧克力”,进化到D(Dove)版本的“德芙”,让人联想到了面向对象设计里的类(Class)实例化(Initialize)过程,这是一个将设计落地、将梦想逐步具象化的过程,边缘平台需要一行代码一行代码的演进,边缘生态也要一步一个脚印的积累,祝愿EdgeGallery能够在落地的路上越走越远。

中国移动研究院网络和IT研究所主任研究员,EdgeGallery社区董事温亮生:祝贺EdgeGallery D版本的发布成功, D版新功能将支持Edge Native架构,通过对AI硬件支持开拓边缘智能服务,中国移动边缘计算平台OpenSigma计划与EdgeGallery生态互通,携手打造边缘计算繁荣生态。


中国联通MEC高级总监陈丹说:作为EdgeGallery的第四个发布版本,很欣喜看到EdgeGallery在3GPP/ETSI标准适配、跨平台能力、AI支持和安全等底层能力增强,也看到在应用生态上能力的逐渐丰富和社区伙伴能力的逐渐注入。在当前5G领域逐渐走向深入技术整合和深化商业价值的实践,EdgeGallery对5G赋能的进一步创新和探索提供了落地的平台和能力。希望EdgeGallery能够进一步吸引更多边缘计算合作伙伴,一起探索5G MEC的无限可能。

腾讯云网络总经理,EdgeGallery社区董事王亚晨:Dove版本成功发布,代表了中国边缘计算开源项目逐渐成熟,并在业界形成事实影响力!希望社区项目能够被更多的合作伙伴采纳,生态越发繁荣!

21CN公司副总经理,技术委员会主任王刚:推进边缘原生,让边缘更智能,满足千行百业数字化转型需求,以开源助力数字中国建设。

紫金山实验室未来网络中心主任黄韬说:非常高兴EdgeGallery社区新版R1.1成功发布,边缘AI、跨平台、边缘原生等新增能力必将提升EdgeGallery在国内各行业的吸引力,社区众多行业创新应用的集成也印证了这一点。希望社区拓展国内影响力的同时,进一步将开源成果推向世界,成长为一个具有全球影响力的边缘计算开源社区。



九州云成立于2012年,是中国早期从事开放云边基础架构服务的专业公司。公司成立九年,始终秉承“开源·赋能云边变革”的理念,完成了从中心云到边缘云解决方案的拓展和积累,建立了完整的“云+边”生态体系和解决方案。九州云已先后为运营商、政府、金融、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供了高质量的开放云边基础架构服务。目前拥有中国移动、中国电信、中国联通、国家电网、南方电网广东公司、中国人民银行、中国银联、中国人寿、中国资源卫星、eBay、国际陆港集团、万达信息、东风汽车、诺基亚等众多重量级客户。