文鼎创智能物联云原生容器化平台实践
作者：sekfung，深圳市文鼎创数据科技有限公司研发工程师，负责公司物联网终端平台的开发，稳固性建立，容器化上云工作，擅长使用 GO、Java 开发分布式系统，连续关注分布式，云原生等前沿技能，KubeSphere Contributor，KubeSphere 社区用户委员会深圳站委员。公司简介
深圳市文鼎创数据科技有限公司创立于 2006 年，是全球领先的线上身份认证解决方案提供商，专注网络身份认证，数据安全领域，坚持稳健谋划，连续创新、开放互助，在金融电子化、政府、企业办公等应用中提供解决方案，成为浩繁国有商业银行、天下性股份制银行、城市商业银行、农村商业银行、各省市税务、政府、各大 CA 机构以及跨国企业的互助伙伴，累积服务近亿用户，不断满足客户差异化需求。
公司多年来连续创新，申请了大量的发明专利、实用新型专利和产品外貌专利；登记了多项计算机软件着作权，同时是国家级高新技能企业；拥有商用密码产品型号证书、密码检测证书、银联认证证书、ISO9001:2015 国际质量管理体系认证及 ISO14001 环境管理体系认证；产品通过了 CE/FCC 认证、RoHS 认证。
公司作为国际线上快速身份验证联盟（FIDO）的核心成员之一，致力于实现全球统一的在线验证标准，我们将运用该技能为差别地域的人们提供享有同等的安全网络世界的权利。
配景介绍
“文鼎创智能物联”是深圳市文鼎创数据科技有限公司针对物联网应用，推出的物联网解决方案，方案包罗统一的物联网服务平台、”云打印机“、”收款云音箱“、”收款云扫码盒子“等旗下产品，为用户的数据安全保驾护航。
作为一家 TO B 解决方案的硬件提供商，“硬件为主，软件为辅”是公司恒久以来的开发模式，因此前期在对服务端的开发、部署、架构设计器重不敷。传统的项目停留在单机（假造机）部署，人工打包上传，不仅费时费力，还容易出错，造成服务的不可用。
在拥抱 K8s 之前，我们也实行过 docker-compose 的方案，相对于人工打包部署，docker-compose 也确实给我们带来了一些便利：
[*]ALL-IN-ONE，提供一键式的软件部署方案，无需实行繁琐的部署流程；
[*]隔离了宿主机系统的差异性；
[*]减少了运维人员进行版本迭代的操作，降低操作失误的可能性。
在面向物联网行业推出新产品，新解决方案之后，对服务的稳固性，以及可靠性带来了新的挑衅，现有的开发模式渐渐跟不上业务的迭代需求，为此我们迫切须要冲破现有的框架，探索新的一套软件迭代流程。
选型说明
在决定拥抱云原生之时，我们对市面上的容器管理平台进行了调研，发现国外 Rancher 用户较多，国内 KubeSphere 位居前列。我们对容器管理平台的选型有几个标准：
https://img-blog.csdnimg.cn/2806839318f0466d9b521cbd1e8ec1b7.png
[*]生态：一个开源项目标生态是否美满很紧张，周边配套的工具能带来极佳的使用体验和可维护性。
[*]社区活跃度：官方堆栈 Issue 或问答社区是否回应及时，代码提交是否活跃？
[*]商业公司或基金会支持：是否有商业公司或开源基金会支持，假如为个人项目，后续停止维护，则可能会给用户带来的肯定的风险。
[*]技能栈：使用的技能栈与团队是否符合，是否有本领解决和维护？
[*]用户体验：是否有 UI 操作界面，界面是否美观，使用流通？
[*]本土化：是否做了一些本土化的优化，符合国人的使用习惯？
在调研选型时，我们发现 KubeSphere 能充分满足的我们的要求。KubeSphere 团队开源的 KubeKey 工具，能资助我们快速搭建一个 KubeSphere 集群，省去了繁琐且复杂的部署流程，OpenELB 项目则为我们提供了本地集群负载均衡的解决方案。
在使用过程中发现的题目，在中文问答社区基本都能找到对应的解决方案。KubeSphere 的控制台简化了 Kubernetes 服务的部署，使得团队一些没有 K8s 使用经验的成员也能快速上手，用过的同事都说好。
目前架构
目前采用微服务设计，开发语言以 Golang、Java 为主，服务之间通信使用 gRPC。
https://img-blog.csdnimg.cn/f88947a83d4b4982ae3bab2c9c270094.png
生产环境使用两个腾讯云 CLB 分别接入来自业务和物联网终端的流量。整个业务服务部署在腾讯云 TKE 集群，并使用 KubeSphere 来管理应用的一样平常发布。而集群的基础设施，本着“能买就买，实在不能买就自建”的原则（并不是不差钱，而是小公司运维压力大）。之所以没有使用 TKE 的控制台来管理应用的发布，主要是 TKE 的控制台体验并不是很友好，另外一个很紧张的缘故起因，应用市肆对第三方 Helm 堆栈支持很差，无法充分利用 Helm 的生态。
https://img-blog.csdnimg.cn/3fb714b41b734cfa94933bb90a70d4d9.png
实践过程
硬件资源
测试环境：10 台 ESXI 假造机，自建 Kubernetes 集群。
生产环境：7 台 腾讯云 CVM 节点，Kubernetes 使用腾讯云托管 TKE 集群。
https://img-blog.csdnimg.cn/42ac2d2e5df34bd1a60416f429dad648.png
存储方案
测试环境：使用 3 台 ESXI 假造机作为分布式存储 Ceph 的 OSD 节点。
生产环境：出于成本和稳固性的考虑，使用腾讯云 CBS 作为 K8s 存储方案。
最小化安装
由于生产环境和测试环境已经有一些外部服务，比如 Prometheus 和 Logging，为了最大化利用现有资源，在部署 KubepShere 接纳了最小化安装。
https://img-blog.csdnimg.cn/a0521004d9cd42f3bd52c06ba7e91410.png
值得一提的是，Monitor 并不是可插拔组件，即使最小化安装，KubeSphere 依然会默认安装，在生产环境中，安装 TKE 监控的 prometheus-operator 会与其冲突，须要关闭 KubeSphere 的 Prometheus 或者手动卸载。
DevOps
在早期开发阶段，版本迭代是一件非常痛楚的事变，开发人员在本地编译打包后人工上传到服务器进行部署。在经历了多次各种环境差异，人工操作失误教导后，团队下定决心改变现有的流程，决定搭建得当团队自身的 DevOps 体系。
https://img-blog.csdnimg.cn/f80516a78eb64fc8a41a65e6265cf081.png
[*]连续集成（CI）：开发在每次提交接码之前都进行 CI，以确保代码的质量和同等性。这包罗运行单元测试，代码静态分析，编译和构建过程等。当 CI 失败时，开发立即修复代码并重新提交。
[*]连续交付（CD）：一旦代码通过了 CI 流程，就将其交付给测试团队进行测试。测试团队进行测试以确保产品的质量。在测试环境，使用了 Coding 的自界说节点作为 CI 的自动化构建，CI 通事后通过脚本自动更新 KubeSphere 的镜像版本。在生产环境，由于涉及发布评审流程，设置变更，各个业务团队的和谐，目前暂时还是交由运维人员手动变更应用版本进行发布。
[*]监控和警报：一旦代码被部署到生产环境，对其进行监控。监控可以资助团队快速发现和解决题目，确保产品的可用性和性能。
目前的 DevOps 实践，主要解决了团队以下的痛点：
[*]统一编译环境：规定项目内应编写 Dockerfile，使用 Docker 容器内的编译环境进行编译，同时使用 Gitlab Runner 通过代码提交事件触发代替开发机本地编译，从而隔离各个开发机环境的差异。
[*]发布版本可追溯：早期项目版本管理十分随意，全凭开发人员心情定名。导致出现题目时无法快速定位。为此，我们约定在 CI 构建时，镜像版本须要满足特定的定名格式，如：${VERSION}-${ENV}-\${CI_NUMBER}，这种定名格式可以资助我们快速定位到某个环境出现题目某次 CI 构建的版本。
[*]平滑迭代：早期项目使用单机单体部署，在进行迭代时，经常有短时间的服务不可用，导致流量损失。在进行容器化改造后，利用 Kubernetes 的探针，可以进行服务的平滑更新，而且在服务状态不健康时，能自动重启，无需人工介入，大大提升了服务的可用性。
[*]运维效率：充分发挥 Kubernetes 的运维体系和云原生的可观测性实践，降低了多业务多环境运维的压力。在服务故障发生时，能够及时感知。
使用效果
流水线设置
https://img-blog.csdnimg.cn/a77e3e7fa4eb4df8bccf55ddb068c2bc.png
流水线使用了 Coding 的方案，有以下几方面的考虑：
[*]能够深度融合企业微信，在 CI 过程，有任何题目能够及时通过 IM 工具关照到开发；
[*]配套工具美满，官方的 Jenkins 有点跟不上云原生的发展，须要安装一系列的插件才能满足需求，设置过程也很繁琐。
应用部署
https://img-blog.csdnimg.cn/a332516b5c234d0b966a58d958e438d0.png
“文鼎创智能物联”项目已全部使用 Helm 应用发布，在使用过程，发现 KubeSphere 一个比力不友好的体验，假如升级应用因 yaml 文件设置错误导致应用升级失败，会无法再次升级。在生产环境中，应用无法升级是一个很糟糕的题目，发现该 Bug 后，已提交了修复代码给社区并归并 fix: can not re-upgrade helm application in a failed state。
集群资源监控
https://img-blog.csdnimg.cn/174977bd501f43389b23d236a1080ee0.png
KubeSphere 内置的监控系统，满足运维人员一样平常对集群健康状态的巡检，同时 KubeSphere 提供了多个层面的监控，针对 namespace 和服务本身，团队使用频次较高的是服务监控，以便开发人员对自身发布的服务的资源使用环境有所了解。
未来规划
[*]“文鼎创智能物联”作为公司探索的新项目已全面完成容器化工作，运行在 KubeSphere 集群，未来计划将历史遗留的 TO B 项目进行容器化改造和迁移到 KubeSphere 集群，提升项目标可维护性和可用性。
[*]探索 Service Mesh 方案，进一步提升服务的安稳发布和可观测性。
本文由博客一文多发平台 OpenWrite 发布！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]