共计 5494 个字符，预计需要花费 14 分钟才能阅读完成。
软件产品只有交付到用户手中才有价值，自己在面向政府等 ToG 场景的软件交付畛域具备数年的工作教训，深知其中痛点。明天借助这篇文章，分享这些痛点以及我的解决之道。
提出问题
自己供职的公司，其次要客户群体是省内的政府部门，所开发的业务零碎是服务于政府内网之中的挪动 APP。作为交付负责人，我始终苦恼于如何将一套基于 Spring Cloud 框架开发而来的服务端业务零碎交付给我的客户。实现软件系统的交付只是万里长征第一步，如何解决前期的运维工作也是必须面对的问题。政府场景的特殊性，为我的工作平添了许多不利因素，这些 ToG 场景交付的痛点，且听我娓娓道来。
离线环境交付
与公网环境隔离，与公司网络隔离，齐全的离线场景是政府交付工作中的标配特色，也是 ToG 交付最大的痛点。置信离线环境交付是所有的交付工程师都不想面对的场景，这意味着所有的交付物必须在当时筹备好，交付过程中一旦呈现任何脱漏和谬误，都意味着今天必须再来现场一次。
交付环境不对立
如果你从事过面向政府的交付工作，那多半会遭逢过交付环境不对立的状况。因为各级政府部门的 IT 建设脚步不一样，同样一套业务零碎，在交付到市级部门时，失去的硬件设施可能是一台物理服务器，而到了省级部门时，则可能失去了公有云提供的数台虚拟机。值得庆幸，物理机与虚拟机的差别并不大。然而近年来政府的 IT 建设始终在向国产自主可控的方向后退，当省级部门要求应用鲲鹏 Arm 架构 CPU，亦或是应用国产麒麟操作系统进行交付时，和市级部门交付环境的差别就曾经十分大了。我甚至不得不将同一套业务零碎在两级部门的交付当作齐全不同的两个我的项目来看待。这体现出不同交付环境之间的差别，而当我转身看向公司开发环境时，开发环境与交付环境的差别，曾经开始让我听到本人头发落到高空的声音了。我很难确定当时筹备好的交付资源，在甲方环境部署时会否遭逢操作系统以及硬件设施差别所导致的依赖性抵触问题。这种问题在离线环境下又被放大，我甚至不具备连贯公网装置软件包来调试解决依赖性抵触问题的能力。
不足自动化运维能力
将软件交付到客户环境中，只是最高级的指标，在合同期内保护软件系统稳固运行是对交付品质更高层次的考验。按照集体教训，在一个软件交付我的项目中，交付部署的工作量，不迭前期运维工作量的一半。咱们是不心愿所有的软件问题都须要工程师亲自到达现场解决的，一来无奈保障 SLA 服务协定中的工夫承诺，其次也会消磨工程师的工作激情。在离线环境下如何构建起一套具备自动化运维能力的软件运行环境，变得尤为重要。依附自动化运维能力，让一些软件故障得以自愈，在肯定水平上升高了政府交付场景中的运维难度。但抉择任何一种技术实现自动化运维的指标都是须要付出代价的，这意味着我须要在软件系统交付之前，后行在交付环境中组装一套稳固牢靠的自动化运维平台。
适度依赖外围人员
在离线化的政府交付场景中，经常面临如下问题：一是交付环境难以对立时，其中非凡之处只被多数全程参加我的项目交付的工程师所理解，而理论教训通知咱们，这些非凡之处往往是一些异常情况的本源；二是离线的工作环境使得工程师通过查问材料来解决问题变成一种奢望，反向进步了对于工程师的教训和技能的技术要求，因而，“合格”的驻场运维工程师很难招到。以上问题造成了一些运维工作过分地依赖某些外围技术人员的场面，一旦外围技术人员到职或者调岗，对以后的业务连续性将会造成较大影响。所有的这些对人的依赖，都在某个靠谱的驻场工程师心愿另谋高就，向我提出辞职申请时痛击我的脑神经。
继续交付艰难
软件交付并非一次性工作。从项目管理的角度来说，用户很难在一开始就提出具体且可落实的需要，具体的我的项目范畴会随着我的项目的推动逐步确定，这是一个渐进明细的过程。而在软件产品交付的过程中，这种渐进明细体现在交付的产品会通过屡次迭代，每次降级后的产品，都间隔用户的最终需要更近一步。而这个继续交付的过程，在离线环境中，所遭逢的难处并不亚于首次交付，甚至会在某些须要回滚的场景中更加简单。在微服务时代，一套残缺的业务零碎往往蕴含了几十个独立的组件，组件数量也为继续交付增加了复杂性。
驻场开发难
驻场开发是一种在政府交付场景中常见的需要。规范的软件产品往往是不能间接满足甲方需要的，这就须要咱们的开发人员能够在甲方办公室间接定制开发指定的几个组件，并疾速更新到线上环境中去，供甲方验证。在理论场景中，少数微服务性能是固定的，只有一两个 jar 包须要频繁更替。
以往的经验
我经验了公司软件产品交付的残缺改革流程。从最开始的 jar 包交付，继而引入容器化技术交付镜像，到起初采纳 Kubernetes 容器编排技术，咱们始终围绕着简单的离线环境进行软件产品的交付工作。每个阶段或多或少的解决了上述各种痛点，所付出的代价也不尽相同。最终咱们拥抱了云原生技术，将业务零碎整体作为新的对象实际了较为简单牢靠的离线环境交付，同时兼顾了以往各种痛点。
Jar 包交付
得益于 Java 开发语言，咱们能够将代码打包成为仅依赖 JDK 运行环境的二进制交付产物——Jar 包。彼时咱们的软件产品还处于初级阶段，业务零碎由 10 个 Jar 包、Mysql 数据库、Redis 缓存、前端 Nginx 组成。
一次交付工作中，首先要搭建起根底运行环境，实现 JDK 的装置。Mysql、Redis 等中间件依附很原始的 rpm 包进行装置，这个过程常常会遭逢包依赖抵触问题。最初将所有的 Jar 包运行起来，启动之前免不得进行一系列的人工配置工作。
这种交付形式比拟原始，咱们会写一些脚本来达成肯定水平上的自动化，然而这只在肯定水平上晋升部署效率，自动化运维能力根本为零。中间件的装置部署对操作系统的绑定水平很高，一旦服务器的操作系统和咱们事后理解的稍有偏差，都可能导致依赖抵触，导致装置失败。而配置过程对人工依赖过重，这在高可用部署的环境中体现的尤为突出，配置各种 IP 很容易出错。
做一个总结，这个阶段咱们实现了简略业务零碎的离线交付，然而没有解决其余任何一个 ToG 场景交付痛点。
引入容器化技术
为了抹平交付环境不对立所带来的复杂度，咱们开始引入容器化技术，通过将所有组件容器化，咱们只须要确保客户的服务器可能运行 Docker 容器，就不须要再放心底层操作系统的问题了。官网提供动态编译版本的 docker 二进制文件，咱们再也不必和软件依赖打交道了。这个阶段，咱们的业务零碎也开始扩大，组件的数量上涨到了几十个，这导致咱们不得不同时引入 docker-compose 以及 docker-swarm 技术来解决单机或高可用场景下的组件编排问题。这些技术同时提供了较低水平的故障自愈能力，间隔真正的生产可用还有间隔。
容器化技术解决了交付环境不对立的问题，然而其余方面的痛点晋升无限。随着业务性能的扩大，一个新的痛点逐步展示进去，咱们须要携带数十个容器镜像进行交付，交付复杂度被交付物数量裹挟着一直回升。
转向 Kubernetes 技术
在交付团队把握了容器化技术之后，为了解决自动化运维问题，咱们开始向 Kubernetes 转型。Kubernetes 技术是能够为业务零碎的交付和运维赋能的，借助于它，咱们的业务零碎实现了较高水平的自动化运维能力。
Kubernetes 技术在故障自愈、弹性伸缩等方面的能力晋升使咱们十分受用，业务零碎真正做到了生产可用。然而同时也带来了新的痛点，那就是它自身过于简单，无论是开发人员还是现场运维交付人员，都必须对它有足够的理解才能够驾驭。换句话说，这种技术的引入大幅度提高了对外围技术人员的依赖水平，甚至进步了对技术团队全员的入门门槛。离线化的交付场景下，对交付环境的后期一次性建设的老本大幅度提高，咱们必须当时在离线环境中筹备好牢靠的 Kubernetes 集群，光这一项工作，就大幅度妨碍了 Kubernetes 技术在交付团队中的推广。
新的痛点
通过了后面的几个阶段，我认为面对离线化的简单交付场景，持续在容器技术以及 Kubernetes 容器编排技术方向上后退是没有问题的，每一次技术选型，都在肯定水平上解决了很多痛点，咱们在交付的过程中曾经不害怕离线环境、交付环境不对立、不足自动化运维能力等痛点，但也引入了一些新的问题，是待解决的。
- 业务性能扩大会同步晋升交付复杂度。这一新痛点从实质上来说，是因为咱们将每一个组件独立对待，而非将整个业务零碎作为整体对待。这样做的后果就是交付物的数量和交付复杂程度间接挂钩，如果能将业务零碎作为整体交付，而非每个组件独自交付，那将极大的升高交付复杂度。
- 每一次新的选型，都引入了新的复杂度，这一点在转向 Kubernetes 技术时尤为突出。这项技术对业务零碎的赋能能力是毋庸置疑的，但无论是一个新环境的首次部署，还是前期的运维难度，对交付团队成员技术能力的要求是直线回升的。为了升高交付团队新成员的入门难度，咱们开始选型一些可能升高 Kubernetes 应用难度的图形化工具，易用性是选型的首要影响因素。
- 继续交付艰难以及驻场开发难这两大痛点，仍然没有被很好的解决。这二者都须要咱们提供机制，解决业务零碎在交付环境中继续变更的问题，前者重视业务零碎整体框架的迭代降级，后者重视某个组件的个性化疾速迭代。
咱们开始将眼光放在了逐步炽热起来的云原生技术畛域。首先，云原生技术是基于容器化技术和 Kubernetes 技术的，咱们曾经具备了肯定的技术根底。其次，云原生技术也重视软件交付畛域的各种最佳实际，其中一些实际十分符合前文中的痛点。通过一段时间的内部测试选型，咱们最终应用了 Rainbond 云原生利用治理平台作为交付工具，实现了全新的简单场景离线交付模式。
云原生离线交付实际
最开始，交付团队外部的一名成员从开源渠道偶尔理解到了 Rainbond 这款产品，并举荐给开发团队人员应用。过后仅仅作为图形化的 Kubernetes 管理工具来应用，以此升高老手开发人员学习 Kubernetes 的门槛。但随着对产品的理解，咱们逐步察觉，Rainbond 真正的用处在于可能解决软件产品的交付问题。
将业务零碎形象为利用
以往的交付过程中，咱们总是将业务零碎中的每一个组件独自对待，然而在 Rainbond 体系中，治理的单元能够放大到业务零碎级别，这种治理单元被称之为利用。利用外部的组件部署和编排都是基于图形化操作的，应用起来不难理解。组件间的调用关系基于拓扑图展示，高深莫测。最重要的是，基于利用这种形象，咱们实现了将组件数量和交付复杂度脱钩，无论利用中有多少组件，咱们始终视之为一个利用。这么做的益处在交付过程中体现的非常明显。
利用模板的离线导出导入
利用一旦部署编排实现，就能够公布成一个利用模板并导出，导出的产物是独自治理的一个包。离线的模板包在导入时齐全不依赖于内部网络，导入实现就能够在离线环境中一键装置，还原为公布时的样子。组件之间的相互依赖关系、配置信息都得以保留，不须要在交付现场重新配置。这一能力齐全扭转了交付的逻辑，从独自交付数十个容器镜像，变成了交付一个涵盖整个业务零碎的包，其中难度的降落可想而知。
简略易用
Rainbond 底层基于 Kubernetes 技术实现容器的调度，提供全面的自动化运维能力。并且将常见的配置从 Yaml 申明式配置转化成为图形化界面操作，极大的升高了入门门槛。引入 Rainbond 体系之后，新入职的工程师能够在简略的培训后，一日之内把握 Rainbond 的应用形式并能够独立交付业务零碎。
原生多云治理
Rainbond 原生反对面向 Kubernetes 的多云治理能力。政府交付场景虽说与公网隔离，然而其实同个零碎内往往具备想通的外部网络。借助 Rainbond 的多云治理能力，咱们将省内多个城市政府部门的交付场景对立治理了起来，在省会建设了对立的治理控制台。这样的部署模式为业务零碎疾速在多个数据中心的交付提供了机制，极大的升高了业务零碎在全省范畴内交付的老本。
继续交付机制
Rainbond 利用模板反对版本治理，当业务零碎有较大改变时，只须要将利用整体从新公布一次，从新导入到交付环境中去后即可一键降级或回滚，极大晋升了业务系统升级效率。在以往解决数十个容器镜像的升降级和配置工作，须要的工夫老本是按天计算的，引入 Rainbond 利用模板的版本控制机制之后，升降级的工夫老本升高为分钟级，操作老本则能够忽略不计。
驻场开发快
当甲方要求某个组件做出些许改变时，应用整个利用级别的模板离线导入显然得失相当。此时，只须要现场开发人员在集体开发笔记本上打包出 Jar 包，通过上传 Jar 包构建组件的能力疾速构建指定的组件，简略的拼装后即可替换对应的组件。这个过程中开发人员只须要提供 Jar 包，甚至不须要学习容器化技术理解镜像打包的机制，Rainbond 会主动解决后续的工作。
总结
我司交付团队借助云原生技术，极大的升高了面向政府的简单离线场景交付工作老本。这种老本节约体现在交付工夫缩短、人员技术要求升高、人员操作老本升高、交付物数量缩小、配置工作量缩小等多个方面。降低成本的同时，也胜利为业务零碎赋能，可能主动解决很多异样场景，实现了自动化运维。不便驻场开发，可能疾速的响应甲方客户的需要，晋升客户满意度。
然而 IT 工程畛域的倒退过程就是在一直面向新的痛点解决问题。目前应用云原生技术也并非可能解决所有的问题，在政府交付场景中，也已经遭逢这一类场景，甲方提出了比拟严苛的要求，禁止应用容器技术进行交付。这种要求从本源上阻绝了云原生交付技术的落地，然而如何优雅的回退到 Jar 包交付的路线中去就成了一个问题，期待社区提供反对，将利用模板转化成为裸机环境可用的交付物，这是后话。