SOFAMOSN 持续演进路径及实践案例 陈逸凡 wugou.cyf@antfin.com 2019.1.6 Service Mesh Meetup #5 广州站Agenda Ø 背景 & 概览 Ø 持续演进路径 & 技术案例 Ø 实践案例 Ø 规划 & 展望 Ø QA背景 & 概览数据平面概览 SOFAMOSN • C实现，支持多语言扩展 • 基于Nginx扩展 • 开发不活跃 开发活跃，最新版为0.4.0 • 蚂蚁+UC主导，重点搭载 SOFAMesh使用，目标服 务通用场景，金融场景SOFAMOSNSOFAMOSN内部模块设计SOFAMOSN数据流SOFAMOSN数据流持续演进路径 & 技术案例能力 0.1.0 0.2.0 0.3.0 0.4.0 Ø TCP代理/7层通用代理 Ø 简单匹配路由 Ø 集群管理 & 基本负载均衡(RR、 RANDOM) Ø SofaRpc及HTTP/1 Service p Client模拟方式:通过蚂蚁内部压测平台建立10w条SOFARPC链接 p 压测内容: 1K 请求/响应持续演进实践总结 ü 架构上，从一开始就遵循分层设计，模块解耦，统一编程模型接口，保证足够的架 构扩展性。 ü 性能上，针对IO、协议、内存、协程进行持续优化。相比最初版本，SOFARPC 协 议上对 0.1.0 版本 QPS 提升了 50%，内存使用减少了 40%；HTTP/2

安信证券 蒋渐峰 安信证券DevOps探索与实践 转型背景 01 工具平台建设 02 试点项目实践 03 目录 CONTENTS 持续改进 04 目标：以研发团队为中心，在端到端流程串联、流程自动化、度量精化、质量增强、资源自助化几个重点方面发力， 打造研发管理平台，提供具备快速交付、高质量、过程透明、可度量的IT研发服务供应链。 证券业务的复杂性： 证券业务种类多，业务规则复杂，业 3个关键方面：文化（Culture)、工具（Tool)、培训赋能（Skill) 工具平台建设 试点项目转型 转型背景 01 工具平台建设 02 试点项目实践 03 目录 CONTENTS 持续改进 04 工具平台建设-从0到1 Jira Confluence 需求 开发 测试 Jenkins 测试平台 Maven Junit Sonar Qube Gradle Nexus 安全 部署 Jmeter Xray Ansible 测试平台 分 析 与 度 量 基础设施 开发环境 SIT环境 UAT环境 生产环境 战略目标 效率 质量 成本 安全 配置管理 落地实践 持续集成 内建质量 部署与发布管理 度量与反馈 工具平台建设-流水线过程 工具平台建设-综合门户 Jira Confluence Jenkins 测试平台 Maven Junit Sonar

并统⼀流程，规范化管理 持续交付 提⾼部署的效率，降低部署的⻛ 险，提⾼部署的质量，消除部⻔ 壁垒，交付过程标准化， 透明化 持续构建与测试 保障代码质量，提升开发效率 知识共享 知识共享与积累，不断完善，持 续学习改进 认证与改进 持续优化， 形成闭环 运维监控 运⾏状态可视化，数据化，降低 部署⻛险，快速反馈 运营统计 全链路指标统计，为持续改进提 供数据⽀撑 学习培训 包 代码质量 管理 多语⾔ 构建 安全管控 构建实 践 测试管理 功能测 试 性能测试 接⼝测 试 产出物管 理 持续构建与测试 ⾃动部 署 配置管理 环境管 理 数据库变 更 运维监 控 通知反馈 部署策 略 持续交付 ⼯具链 最佳实践 测试管理 规范 流⽔线建设 规范 敏捷开发 规范 流程协作与最 佳实践 项⺫管理 进度 管理 知识共享 知识 库建 设 ⽂档 协作 学习培训体系 培训规划建设 平台培训 ⼯具培训 培训效果评估 LAB 环境建设 标准案例建设 知识库建设培训 成熟度评审 度量驱动改进 认证与改进体系 已选⽤⼯具 JIRA Confluen ce GitLab Mave n Junit Nexus Sonarqub e Jenkin s Slelenium RedWoodH

Rights Reserved. Thoughtworks 技术雷达 关于技术雷达 Thoughtworker 酷爱技术。我们致力于建造技 术，研究技术，测试技术，开源技术，书写技术， 并不断改进技术。支持卓越软件并掀起 IT 革命是 我们的使命，Thoughtworks 技术雷达就是为了 完成这一使命。它由 Thoughtworks 中一群资深 技术领导组成的技术顾问委员会，通过定期讨论 试验：值得追求。重要的是理解如何建立这种能 力，企业应该在风险可控的项目中尝试此技术。 评估：为了确认它将如何影响你所在的企业，值 得作一番探究。 暂缓：谨慎推行。 新的 挪进 / 挪出 没有变化 雷达一览 技术雷达持续追踪有趣的技术是如何发展的，我们将其称之为条目。在技术雷达中，我们使用象限和环对其进 行分类，不同象限代表不同种类的技术，而圆环则代表我们对它作出的成熟度评估。 软件领域瞬息万变，我们追踪的技术 们讨论了远程软件开发实践和工具的成熟，和团队们 如何继续以有效协作为重点，不断突破界限，在一个更加分散和动态的环境中进行工作。一些团队利用新的协 作工具不断提出创新解决方案。其他团队则继续调整和改进现有的面对面实践，例如实时结对编程或集体编程、 分布式工作坊（例如 远程事件风暴）以及异步和同步沟通。远程工作提供了许多好处（包括更多样化的人才储 备），但面对面交流的价值是显而易见的。团队不应

Platform 生命周期政策 。 第 第 1 章 章 OPENSHIFT CONTAINER PLATFORM 4.14 发 发行注 行注记 记 3 1.3. 新功能及功能增强 此版本对以下方面进行了改进。 1.3.1. Red Hat Enterprise Linux CoreOS (RHCOS) 1.3.1.1. RHCOS 现 现在使用 在使用 RHEL 9.2 RHCOS 现在在 OpenShift 请参阅 AWS 本地区中快速设置集群。 1.3.2.21. 使用手 使用手动维护 动维护的云凭 的云凭证 证的集群 的集群简 简化的安装和更新体 化的安装和更新体验 验 此发行版本包括更改，用于改进安装和更新以手动模式使用 Cloud Credential Operator (CCO) 的集群进 行云供应商身份验证。oc adm release extract 命令的以下参数简化了云凭证的手动配置： Serverless 功 能，以便您可以使用带有 CloudEvent 或 HTTP 请求的 Serverless 功能。 查看 BuildConfigs 和 Shipwright 构建的最新构建的状态、开始时间和持续时间。您还可以在 Details 页面中查看此信息。 1.3.4.2.1. 新的快速开始 新的快速开始 在这个版本中，存在新的快速启动，您可以在其中发现开发人员工具，如安装 Cryostat Operator

PLATFORM CI/CD 概述 OpenShift Container Platform 是面向开发人员的企业就绪 Kubernetes 平台，使组织能够通过 DevOps 实践（如持续集成(CI)和持续交付(CD)）自动化应用程序交付流程。为了满足您的机构需求，OpenShift Container Platform 提供以下 CI/CD 解决方案： OpenShift 构建 OpenShift ilder）。对于 docker 和 S2I 构建，生成的对象为可运行 的镜像。对于自定义构建，生成的对象是构建器镜像作者指定的任何事物。 此外，也可利用管道构建策略来实现复杂的工作流： 持续集成 持续部署 2.1.1.1. Docker 构 构建 建 OpenShift Container Platform 使用 Buildah 从 Dockerfile 构建容器镜像。有关使用 Dockerfile Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。 OpenShift Container Platform 上的 Jenkins 镜像被完全支持，用户可以按照 Jenkins 用户 文档在作业中定义 jenkinsfile，或者将其存储在

1.2.2.10. 集群升级前所需的 Operator 的最新版本 1.2.2.11. 没有置备网络的部署 1.2.2.12. 部署现在支持 root 设备 hints 1.2.2.13. 安装程序的改进 1.2.2.14. 安装时选择 RHOSP 可用区 1.2.2.15. 在 RHOSP 上安装时不再需要浮动 IP 地址 1.2.2.16. 为 RHCOS 安装选择磁盘 1.2.2.17. AWS 支持的功能 1.2.2.19. IBM Power 系统 限制 支持的功能 1.2.2.20. Red Hat Virtualization（RHV）全堆栈安装程序的改进 1.2.2.21. 使用安装程序置备的基础架构为裸机部署改进修复失败的节点 1.2.3. 安全性与合规性 1.2.3.1. Compliance Operator 1.2.3.2. 配置 OAuth 令牌不活跃超时 1.2 16 16 16 16 17 17 17 17 17 17 17 18 目 目录 录 1 1.2.5.1. 改进了 Web 控制台的升级体验 1.2.5.2. 改进了使用 OperatorHub 的 Operator 安装工作流 1.2.5.3. 改进了操作对象详情视图 1.2.5.4. 查看集群 Operator 的相关对象 1.2.5.5. 编辑受管资源时的警告信息 1

在提交问题单的同时提供您的集群信息，可以帮助红帽支持为您进行排除故障。 这类信息可使用 oc adm must-gather 命令来收集。 唯一的集群 ID。 访问其他产品文档。 如果您对本文档有任何改进建议，或发现了任何错误，请访问 http://bugzilla.redhat.com，针对 OpenShift Container Platform 产品的 Documentation组件提交 Bugzilla Container Platform 会收集有关集群健康、使用情况和集群大小的匿名聚合信息，并通过两个 集成组件（Telemetry 和 Insights Operator）向红帽报告。红帽利用这些信息便可改进 OpenShift Container Platform，并更快地对影响客户的问题做出反应。这还可以简化红帽客户的订阅和授权流程， 并使 Red Hat OpenShift Cluster Manager 会向红帽发送一组精选的集群监控指标子集。这些指标会持续发送并描述： OpenShift Container Platform 集群的大小 OpenShift Container Platform 组件的健康和状态 正在进行的任何升级的健康和状态 有关 OpenShift Container Platform 组件和功能的有限使用情况信息 有关集群监控组件所报告的警报的摘要信息 红帽将使用这一持续数据流实时监控集群的

序。每个容器都带有各自的依赖软件，并且管理自己的接口，如网络和文件系统，因此应用程序无需争用 这些资产。 1.1.2.2. 部署和 部署和扩展 展优势 如果您在应用程序的主要版本之间进行滚动升级，则可以持续改进应用程序，既不会造成停机，又能仍然 保持与当前版本的兼容性。 您还可以与现有版本一起部署和测试应用程序的新版本。在部署了当前版本的同时，还部署应用程序的新 第 第 1 章 章 OPENSHIFT 版本，可存储数百万镜 像和标签。 OpenShift Container Platform 中的其他 Kubernetes 增强功能包括软件定义网络 (SDN)、身份验证、日 志聚合、监视和路由方面的改进。OpenShift Container Platform 还提供功能齐全的 web 控制台和自定义 OpenShift CLI (oc) 界面。 1.1.3.4. OpenShift Container 得以扩展或复制，在需求增加时为客户端提供更多实例，在需求下降时缩减为更少的实例。 以不同的方式运行，具体由应用程序的类型决定。例如，一个应用程序可能每月运行一次来生成 报告，然后退出。另一个应用程序可能需要持续运行，并且必须对客户端高度可用。 受到管理，以便您可以监视应用程序的状态并在出现问题时做出反应。 容器得到广泛接受，对能让容器适合企业使用的工具和方法的需求也随之诞生，这使得容器有了丰富的选 择。