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