基础的服务包括分布式日志、立体式监控、容器镜像仓库、开发包管理等 。
? 3）服务插件的能力
通过服务插件能够提供屏蔽中间件部署 ， 提供统一的管理 。 这里的插件包括开源的中间件、云厂商的 SaaS 服务和企业内部已经建设的内部其他系统 。
4、DevOps 研发效能
基于云资源弹性引擎 ， 在建设业务系统时能够不受异构基础设施的影响 ， 能够做到以应用为中心 。 进一步 ， 为了提高项目研发效能 ， 我们实现一站式的应用编排、CI/CD和持续交付 ， 同时实现了一站式的项目人员大协同 。
5、应用编排
通过让开发者声明的方式告诉平台微服务运行的整个环境 ， 而由平台负责将这个声明编排成环境的搭建过程 。 我们通过一个 yaml 文件的方式让用户进行声明 ， 分为两部分：
一部分是微服务的声明 ， 包括有哪些微服务 ， 以及各个微服务所需的资源、副本个数、端口、环境变量 ， 甚至是对外网关的域名、网关的转发设置 。
另一部分是扩展服务的设置 ， 我们称之为 add-on ， 而中间件就是其中的一类 add-on ， 可以看到开发者只需要声明应用用到了哪些 addon ， 比如 mysql ， 指明 mysql 的规格、版本即可 ， 平台会自动为应用创建这个 mysql ， 并将 mysql 的配置通过环境变量的方式传递给微服务 。 并且 addon 是支持扩展的 ， 通过这一开放的方式 ， 可以将所有的三方依赖集成进平台 。
Kubernetes 也提供了 yaml 的声明方式 ， 那为什么不让开发者直接用 Kubernetes 的 yaml？这里需要强调一点 ， 那就是“关注点分离” 。 Kubernetes 本身不是一个面向开发者的平台 ， 而是面向平台的平台 。
文章图片
图中列出了我们平台的 yaml 和 Kubernetes 的对比 ， Kubernetes yaml 中有太多开发者不需要关心的基础设施方面的细节 。
虽然事实上我们平台的 yaml 底层实现也是如此转换成 Kubernetes yaml 去进行部署的 ， 但我们认为开发者应该关心自己需要关心的 ， 而平台应该将用户不需要关心的事物彻底屏蔽 。
最后 ， 通过这一文件 ， 开发者在中心平台经过验证的部署过程 ， 几乎不需要修改就能同时适配到客户环境 ， 为一键部署打下了基础 。
6、一键部署
最常规的方式就是通过编写脚本来串联编译构建以及部署的过程 ， 来完成CI/CD 。 最开始我们也是通过 jenkins 拼凑脚本来实现的 。 但是对开发者而言 ， 他关注的其实是最核心的那条编译命令 ， 而其他准备和善后工作都应该由平台负责完成 。 按照这个思路 ， 我们通过流水线 yaml 文件编排 CI/CD ， 屏蔽底层细节 。
我们设计了一个极简的配置语法 ， 整体只有 stage / action 两级 。 stage 就是阶段 ， 它用于控制串行和并行；action 则是实际的执行单位 。 action 不等于脚本 ， 其被设计成高度封装的功能逻辑 ， 可以被参数化使用 。 并且 action 是支持扩展的 ， 理论上任何短时任务/作业都能被封装成 action 。
推荐阅读
- 于本|豆瓣 App 安卓新版本 7.20.0 测试
- 苏宁|可循环包装规模化应用 苏宁易购绿色物流再上新台阶
- 产品|泰晶科技与紫光展锐联合实验室揭牌
- 相关|科思科技：无人机地面控制站相关设备产品开始逐步发力
- 生活|数字文旅的精彩生活
- 解决方案|【干货】反渗透设备结垢原因及解决方案
- 手机|【直播纪要】VR/MR会吹响消费电子反攻的号角吗？| 见智研究
- 技术|聚光科技旗下临床质谱仪获批医疗器械注册证
- 智能化|龙净环保：智能型物料气力输送系统的研究及应用成果通过鉴定
- 爆发|中信证券：自动驾驶渐行渐近，惯性导航刚需爆发