DevOps 助力用友 BIP 数字化转型提能增效

1. DevOps助力用友BIP 数字化转型提能增效用友技术架构师 / 邵书超

2.

3. 个人简介邵书超，用友技术架构师，目前负责用友YonBIP云原生技术与产品的架构和研发工作擅⻓云计算、容器、DevOps和网络安全等领域曾经负责多家企业的DevOps平台建设，微服务容器化迁移等工作

4. 目录 1. YonBIP的云原生架构 2. YonBIP基于Serverless的持续集成与交付系统 3. YonBIP的云机一体开发调试体系 4. YonBIP的哈勃监控中心

5. 用友BIP ｜商业创新平台

6. 企业服务产业走到数智化新时代

7. YonBIP服务架构

8. CNP（云原生平台） • Gartner预测到2025年，对于数字化转型的基础，CNP将从2021年的不到40%上升到95%以上 • CNP 运用云计算的核心能力，提供可扩展的弹性IP及相关能力服务，从而加快价值实现并降低时间成本

9. YonBIP技术平台(iuap)发展历程

10. iuap支撑YonBIP实现数字化转型

11. 目录 1. YonBIP的云原生架构 2. YonBIP基于Serverless的持续集成与交付系统 3. YonBIP的云机一体开发调试体系 4. YonBIP的哈勃监控中心

12. 流水线支撑YonBIP云上云下持续交付

13. 持续集成与交付(CICD)系统面临的挑战

14. YonBIP技术平台的解决方案

15. 云原生流水线架构示意图 • 定义Pipeline, Task, PipelineRun等CRD描述Task，流水线，流水线执行实例等 • 使用自定义控制器调度和管理流水线的执行 • 流水线的每一个步骤，对应一个Task，以Pod的形式运行于专⻔的用于构建的K8S集群中

16. 流水线运行流程图

17. 目录 1. YonBIP的云原生架构 2. YonBIP基于Serverless的持续集成与交付系统 3. YonBIP的云机一体开发调试体系 4. YonBIP的哈勃监控中心

18. 云原生架构下的微服务调试面临的挑战 • 由于本地网络和Pod网络一般不通，必须将用于调试的Pod以 NodePort的方式暴漏出来，而Nodeport会占用集群内所有主机的端口，这样增加了端口冲突的可能性，增加了集群的运维成本 • 如果没运行服务的Pod开启调试端口，当此Pod出问题时，会阻塞整个系统的可用性；如果单独开启专⻔的用于调试的Pod，则会占用过多的云计算资源 • 每次代码修改都需要通过流水线发布到云上，效率低下

19. YonBIP的云机一体解决方案 • 云：运行微服务的，运行于云端的K8S集群 • 机：运行开发调试中的微服务的本地机器 • 云机一体：将本地机器“接入”位于云端的K8S集群，以方便进行高效的本地调试

20. 远程调试与云机一体本地调试对比

21. 传统本地调试与云机一体调试流程对比

22. 云机一体特性

23. 云机一体实现原理 • 注册中心多版本注册：注册中心支持多版本注册，可以区分云上版本和本地版本。 • 注册中心多IP注册：支持本地网卡多IP注册，以适配 VPN使用场景；支持Ingress域名注册，支持从本地仿问Pod • 调试标识：浏览器通过cookie标识请求为调试流量，此调试标识与本地服务的版本号匹配 • 流量转发：通过Nginx Ingress Controller的lua插件，通过请求携带的cookie标识查询本地IP地址并进行转发 • 标识传递：RPC/REST调用必须持续向下传递调试标识，以支持服务的多级联调

24. 使用流程

25. 使用示例

26. 目录 1. YonBIP的云原生架构 2. YonBIP基于Serverless的持续集成与交付系统 3. YonBIP的云机一体开发调试体系 4. YonBIP的哈勃监控中心

27. YonBIP哈勃(Hubble)监控中心 - 四大⻆色工作台

28. IT管理工作台主机资源监控列表主机资源监控详情

29. 运维工作台告警列表告警详情：包括火焰图， JVM性能分析等数据

30. 开发工作台慢SQL查询业务日志查询

31. 开发工作台 Hubble链路录制 Hubble分析报告

32. 性能工作台 - 火焰图火焰图生成示例，可手工触发，也可由报警触发

33. 故障诊断实践 - 发现问题 CPU/内存占满 K8S事件监控: Pod重启

34. 故障诊断实践 - 慢SQL分析根据慢SQL分析可以查出故障发生期间的慢SQL语句

35. 故障诊断实践 - 访问日志分析根据Ingress访问日志可以得知大量状态码为499的请求，其代表服务端响应太慢，客户端不再等待

36. 故障诊断实践 - 业务日志分析根据业务日志的查询分析，此服务有大量的sql查询异常。至此基本可以认为是大量的 SQL查询将CPU和内存打满

37. 故障诊断实践 - 火焰图分析通过性能工作台的火焰图功能，确实可以发现此服务产生了告警并触发生成了火焰图

38. 故障诊断实践 - 火焰图分析观察此火焰图你能得出什么结论？ 1. 一个大粗柱子上面两个大平顶，而且是两个不怎么耗CPU的操作，分别是 long tostring和hashmap get，说明整个进程的绝大多数CPU时间都花在这里了。这就是一个典型的死循环的火焰图构型。 2. 此火焰图共采样32000次，录制时⻓60s，采样频率100Hz，32000/60/100, 说明此时大约6个线程在这个死循环里。而此实例正好6个核，说明此进程基本消耗了此实例所有的CPU资源。 3. 由此导致sql查询都变成慢查询并有大量连接超时。 4. 根据火焰图显示的调用链，可以迅速定位到相关代码。对于此问题，是由于 SQL查询没有设置相应的约束，导致返回大量的数据；而接下来的代码对这些数据进行遍历导致了问题的发生。 5. 问题的解决：给出问题的SQL查询加上相应的约束以返回期望范围的数据。

39.

40.