技术中台解决方案

概述

随着软件行业的发展，企业信息化的推进，原先的烟囱式开发模式以及单体架构越来越不能适应信息化的浪潮。面对项目更迭周期的缩短，业务的复杂化，服务的多样性化，技术中台则能能很好面对挑战devops技术中台，通过整合形成PaaS基础平台，使整体开发、测试、运维、项目管理等形成一体化。

技术架构

方案架构

技术中台集成研发体系服务、运维管理与监控告警为一体，为业务中台与数据中台提供支撑，形成自动化体系。

集成服务

为业务中台，数据中台提供基础服务，使它们可以集中于自身的管理，包含权限，授权，存储，通知等常用服务，各个服务之间通过 http 方式调用，解除服务之间粘连。为上层服务提供强有力的支撑。

运维

持续集成，持续发布以及运行环境管理，为项目的快速构建、快速发布、及时排错提供支撑。使用 git 作为版本管理器管理版本，方便版本管理，使 jenkins 作为发布核心，能轻松发布项目，使用 k8s 作为容器编排器 ，方便地管理容器，再加上 kubaord 作为管理平台，能方便地管理应用。

监控

使用k8s方便且快速地查看日志，快速定位问题。通过钉钉告警及时通知工作人员，让工作人员及时了解情况，解决问题；通过 pretheus+granfana， 能快速查看服务器及数据库状态。

方案优势

项目更迭周期越来越短

随着信息行业市场竞争的日趋激烈，对软件的要求也越来越严苛以及多样，从而导致项目更迭周期越来越短，这就导致软件质量越来越难以控制，因此需要优秀的持续集成，持续发布管理。

业务逐渐复杂化

客户的需求变多，导致业务变的越来越复杂，而复杂的业务则会导致开发周期变长，自动化流水线的结构，使得业务发布，迭代更新更快，业务稳定性更强。

部门工作结构清晰

技术中台是整个中台体系的支撑，因此需要确定好各个构成组件，明确组件的职责 , 明确划分服务，确认服务边界，服务与服务的互通方式，并且这些都不是技术人员自己去想当然的任务该有哪些，该做到什么程度，而是要以公司现在以及未来的业务方向为明确依据。

持续集成、持续发布规范设置

拆分成多服务也要求代码结构有相似性，命名也要有规范，不然对开发很不友好，这个这样项目结构，这样命名，那个那样项目结构，那样命名，开发要先发力气去搞清这些东西，另外就是构建时，如果没规划好项目结构，导致要根据每个任务写相应的任务配置，几个任务还好，任务一多就不好管理，并且新入运维也不好接替工作，因为他需要一个一个去看这些任务配置。

轻松发布部署

使用 git+jenkins+k8s 方式： 使用 git 作为版本管理方式，方便且高效；jenkins 一次配置，持续使用，从此和打 jar 包，打 war 包然后复制粘贴到服务器上说拜拜；代码中包含 k8s 的 yaml 配置文件，轻松修改；使用 k8s 管理监控应用，伸缩方便，日志一目了然。

告警通知

集成告警通知到钉钉，能及时发现问题，分析问题，解决问题，保证环境稳定。再也不用时不时跑到监控页面去查看情况了。

完备的持续集成，持续发布规范

有完备持续集成规范，代码分支有相应命名规范，代码提交有相应的提交信息规范，使得代码基线清晰明了，也能很轻松知道别人改了什么；规范化的代码结构可以让 jenkins 任务配置得以按同一模板来配置，使得 jenkins 配置更为简便，减少了运维工作量，也让新入员工能更快接手工作每个项目都按 k8s 的发布配置模板进行发布配置，能让开发人员只需要知道配置文件的环境变量在哪设置，使得 devops 流程更加顺畅，同时也使得开发人员不需要对 k8s 的技术栈很深。

其它

• 无