我对国内行业软件发展的一些心得和规划

此文为国庆主题,内容是在工作和当前行业接触过程中,在十四五发展的规划,还有当前国内外行业环境下的一些心得体会,这里属于自己个人观点。

背景

这个是一个国内外发展变革的时期,这里从两个维度交待背景,分别是国际和国内。

当前国际环境格局变动,俄乌战争,美国技术封锁,中国一路一带发展等,这些大国的发展,影响着整个国际社会的变革。乌克兰战争的爆发,欧美的对俄的制裁,对俄的封锁,更是体现出国际环境技术自主发展的重要性,各个国家意识到和平统一,谋求共同发展,光刻机、芯片等限制,突出体现基础核心产业的重要。中国一路一带的发展,朋友圈在世界扩大,前期上合峰会的发展,更体现出亚太地区的经济的发展变化,整体亚太版块的结合更加紧密。

国内而言,中国制造业、互联网在国际名列前端,核心技术不断突破,数字化和AI的发展,更加将技术自主更加深入人心,国产化的技术在国内兴起,已经形成趋势,云技术和数据治理技术的普及,使得当前平台化,自动化成为主流,核心的技术产品和业务的中台化,在国内已经形成不可挡的方向,形成平台化的产品在各个头部互联网企业体现,比如物联网、人工智能、数据中台、城市大脑等,阿里云、腾讯云、华为云的云计算发展为各行各业赋能,形成大中台提供技术,前端团队形成交付模式,新的软件发展模式已由传统进一步转变提升。

概述

在国家崛起的这个时期,输出自己的技术能力,贡献自己的能力,这是自己对强国的一种体现。

基于以上背景,国家政策的实施,身在软件行业中的个人或者团体,都有体会在国家崛起的时期,针对于我个人的定位和发展,输出自己的能力和一些力所能及的发展贡献。在这个过程中,虽然国内有一定的发展,但也会体会到国内外软件的差距,不仅仅是芯片,在基础软件的建设,行业软件的建设同样还需要努力,互联网还有各个技术依赖于基础软件,行业软件需要各个高新技术的支撑。

自己本身处于行业软件,在这块上的体会比较深刻,国内千万个行业的发展,每个沉淀需要很长的周期时间,需要不断的去提升,打磨提升行业软件的服务能力,解决方案能力,结合更多的主流技术进行提供出更好的解决方案和用户体验,科技创新,提升业务本身的价值性和软件服务的优势。

当前专注在公积金发展上,自己从自身的了解和体会上,从三个角度和多个思考体会点,阐述自己的观点,我有我思:

  • 公积金行业的发展:行业的发展和现状的思考,了解当前的问题和现状,明确本身行业的需求和发力点。
  • 企业团队的定位:团队角色的定位,自力能力的认识,明确自己的角色和适合自身的发展点。
  • 发挥自我价值的思考:需求和自身的匹配,让自己更加专注和发展,提升自我价值和更深入行业思考。

为了更好的描点阐述和自己从其它行业的思考,下面的标题做了缩减。

行业发展

行业和发展需要新一代人的深入,新的思维和新的理念的介入,体现行业的创新和服务的提升。

公积金行业自己接触的并不是特别长,但也不是很短,总下来的几年,看到的了解的,多少有些体会,这里陈述自己的理解,同时也结合自己在其它行业经验进行的陈述。

相对而言,行业软件的发展由原来10年前的单体架构已经提升到的分布式架构,公积金本身大部分或者多个城市属于传统现状,而这也是本身业务性质的稳定性要求,还有业务范围本身等原因。公积金的业务属于比较稳定型(这里的稳定指的是核心业务)和各个对接的第三方、外围等,而个性化的区域和业务,还有流程等,偏向于局面地区,而这个也形成了各个区域不同的门槛。同时业务的复杂性还有行业的沉淀性较强,对一般性的人员接触,都是在有自我公积金之后才进一步的初步了解,基于这个,人才的积累还有资深层面上,是有可预见性的,人员并不多,类似于电商行业,可能很多人都特别了解它的业务,而相对理解公积金业务的,达到资深的,其实行业内还是比较少的。

基于以上种种情况来说,政策、区域、人才、还有个性化等特殊性,造就一个局面,就是公积金业务相对传统,大部分来说,使用的软件技术还有创新性上就比较少,整体偏向于传统行业。

另外在行业竞争的这多家里面,能有大城市大项目经验的还是数得过来,而这个针对当前团队来说,是有一定的优势的,而基于以上的局限性,也有对手尝试打破的,比如产品化的提升,产品化的输出再加上互联网的思维打法,在全国性铺开。当然接触并不是很深入,但是从整体还有各个反馈来说,虽然铺开,但是也同样分散开来的手掌,在一定程度上,也会有受限,毕竟全国的业务就是那么多,那么大。在江浙一带的,由于互联网的优势,有一些突破,但是表现貌似并不是那么突出点。

近几年软件行业的发展非常迅速,人工智能场景的不断突破,技术还有数字化的不断加持,传统的公积金行业受到刺激,大家都在不断的找方向,这个过程中,也是期望能看到不一样的试点和服务突破,很可惜,当前还没有遇到。

针对于以上种种,也许还有很多。结合我们团队在做公积金业务中台,中台化的建设和思维,这个是自己特别看好的,看好的原因并不是单纯的架构,而是一种行业的变革,一种全新的软件模式。

这里也提出自己对业务中台的理解,中台化的思维更像是一种公积金操作系统,进行基础的操作系统安装,把公积金的核心业务的元数据和主数据进行沉淀,其它的软件像搭建积木一样的让各个团队去建设,形成一套公积金业务中台产品,而这个就是产品能力的输出,把这个概念传输到全国,加上一线城市大项目的落地案列,在可把控的操作下,形成产品化,形成一体化,加上中台特有的架构形成数据沉淀,形成标准,更好的输出到全国,有数据,有AI,有场景,形成进一步的公积金业务大脑,形成新的服务概念,新的业务创新输出。

业务中台是一个土壤,在这个上面积累和形成人才、业务、新产品、人工智能等的成长,最终形成行业多个插件或者产品形态的插件,形成一套行业解决方案,甚至后期可以结合元宇宙,足不出户,就可以办理公积金业务。当然,这套也可以复制到其它的行业,促进其它行业的发展,或者扩展到海外(就是不知道海外有没有公积金)。

整体行业的现状,结合自己的理解还有对行业发展的期望。

团队定位

一个人有自我清晰的认识,就能在团队找到定位和促进团队的进步,发挥自己的优势。

行业的发展需要人才的支撑,这里的人才并一定要达到什么条件,这里主要是表达符合时代的发展需要,在对应的岗位,对应的工作,对应的能力范围内,力所能力的输出自己。

在对行业的现状的做的同时,清楚的定位自己,能了解自己的能力还有所擅长的,喜欢和热爱自己的工作,在这个点上发光发亮,能我所能,达我所达,促进某一项的发展,在国家发展和崛起下,也是一种价值体现。在软件行业接触差不多近7年,在接触的团队还有方面的认识下,自身也有不断的认识。从初始的兴奋,到迷茫,到发现不足,到努力,到再认识自己,在这个成长过程中,需要感谢到很多,也同步建立自己的工作观和人生观,学会面对,学会去做好一件事,同时也学会团队的相处,更加清楚自身的限制。

这个过程中的打破,更多的是在公积金行业,首信团队中的体会,团队的互相成长,包容,还有协助,同时还有互相感恩,当然,还有硬技术,这些有部分除了自己有努力和领会,但是在我的感觉更多的是团队给的,对首信公司,对我自己而言,本身就带有比较浓厚的个人情感,在这个基础之上,会更多确定自己的输出还有团队定位。

在一个人拥有的一个热爱的心态之后,在对事情还有做事上就会提出自己的想法还有主动性提升,这点自然自己也有。我更期望的是能在团队中发挥自己,更多的让大家看到,看到的不是我,而是为团队推进出成绩,让大家看到我们的发展,提升热情,提升目标。我始终相信在这样的氛围下,大家会共同进步,共同努力,一起发展,进而推进公积金行业的发展,这是我所想看到的,也是想做的。成果是团队的,大家的,也是我的,也许这个就是自己所追求的定位。

有了方向,定位然后就很清楚,在未来的3-5年(自己只能看到这么远)中,当前技术还有中台产品建设输出的情况下,我更多的是协助和提出自己在过程中的经验,在团队大的目标下,结合自身具备的一些技术优势,一些成长经验进行传输他人,发展和落地中台的内容,协助两广区的同事解决过程的技术问题,也在过程中自我学习新的技术内容,新的解决方案,推进和解决我们的问题,提高前端业务的技术能力,同时也期望自己的本身经验,对中台产品的进一步打造和输出,形成我们公积金业务的标识和品牌,这个是我们的进步,这是行业的发展的一个进步。

即是自己所喜欢的,也是自己所热爱的,更是自己所期待的。

自我价值

每一代都有每一代特有的使命感,期望能为团队做好一些成果,在回想的时候能自己回味下。

能有所期待,即有目标,同有方向。在公积金行业的发展历程上,也许我们只是一个过客,一个不会有人记得的角色,更是一个默默无闻的程序员,但是这并不影响我们对行业输出我们自己,并不影响我们自己的价值,在对应的岗位上,做好自己,做好我们这一步需要做的,承接上一代人的理想,承接上一代人的精神,我们有自己特有的角色,特有的使命。

在中华民族百年复兴里面,中国改革发展40年,已经建立了一个又一个奇迹,这个过程,一波又一波的洪流,一代又一代人的推动,他们在兢兢业业的岗位上,付出自己的青春,付出自己的汗水,付出自己的知识,成就新一代人的梦想。

在前一代公积金业务中,无数的公积金人给我们建立好了基石,他们打下了公积金行业的基础,从公积金的制度初起立,在这个制度还有国民住房中发挥着重大的作用,解决了一代人的住房问题,这是我们所能看到的,也是全国在受惠的,正是他们的努力,开创了行业,推进了行业,促进了国家的发展和进步,促进了中华人民的安定和繁荣。这些成果和业绩,是值得我们尊重的,也是值得我们学习的。

而在我们这一代,不管是技术和经验,能力都在稳定的阶段,也是发力的阶段,更是在创新的阶段。在新一代公积金业务中台的建设,结合当代最新的技术还有科技使命,在国家的数字化,还有科技进步发展下,融合更多的新技术,比如云计算、大数据、人工智能、自动化能力等等,为业务的发展和创新提供了条件,新一代公积金业务中台为这个打下了基础,促进了行业的更进一步的发展和提升。在这个建设过程中,不仅仅是一份工作,更是一份事业,一份使命感的存在。在只是这一波洪流里的,在未来的5年里面,自己也在思考输出自己的力所能及,促进新一代中台的发展,进而公积金行业的发展,这是自己想看到的,也是想留下的。

总在有一天,回想后面的5年,自己曾经做过这样的一个事,可以有自己单独的回忆,自己能回想或者说得出来的事情和成果出来,这也许就是自己追求的价值。

收尾

以上是自己的过程和思考,仅以此文进行自我勉励,自己可以得到更多的认识,吸引更多同类型的人一起共同努力,共同发展和创造价值。在自己这勿勿的三十年里,在软件行业里面,我们需要很多突破,同时也更加需要有人可以提出自己的观点,尽自己微薄之力推进行业软件的发展。

在国际大变革的情势下,我们在软件技术的自我发展,国家在不断的输出自己的国际影响力,一带一路建设,上合组织的影响力,整个亚欧大陆正在连接,中国正在崛起。千年华夏,百年屈辱,党改革开放40年,中华民族伟大复兴的时期,在国家不断前进的同时,身处这个时代的我们,在自己的努力和行业岗位做好我们自己,通过这样的方式表达是自己对复兴强国的贡献。

最后,在这个发展的过程,同时也是对我们首信人的期望,不会遗忘自己是国人在当代的使命,输出自己的技术能力,贡献自己的能力。

使用ACP技术规避数字化建设基础层问题

在从事IT行业以来,在业务建设过程中,一直无法规避的问题,就是基础层建设,建设消耗的人力物力极大,在做架构带团队的时候,这个更加体现。

此文档为ACP能力输出方向和解决方案之一。

概述

国产化的趋势是方向,更多的业务建设还有数字化整合国产化,安全化的要求,比如国密要求,数据上链(区块链)等,同时也产生出新的行业问题体现。ACP中台的解决和规避数字化建设的相关问题,这些由中台层进行完善和考虑,整体架构如下:

方案描述:

  • 利用中台的优势,进行多方和各种基础层的规避,做好角色责任划分;
  • 利用中台的优势解决国产化、数字化、安全化的问题;
  • 让数字业务建设过程中,对相应的基础层建设透明化。

常见基础层问题

当前行业发展和国家的战略要求,在数字经验上,提到自主可控,国产化等要求,这几块上,国产化的建设当前涌出很多,特别明显的芯片、数据库、操作系统等,这几块对数字经验,数字业务上提了进一步的要求点,列了以下几点:

  • 网络安全和各种加密的问题
  • 云平台兼容适配的问题
  • 多国产化数据库的兼容
  • 国产品系统和前端兼容的问题
  • 数字建设第三方问题
  • 新技术框架的整合和融入
  • 新旧技术衔接问题
  • 数据采集成本的问题
  • 数据抽取存储,治理运营的问题
  • 自动化运维监控的问题
  • 自动化版本管理业务集成的问题

问题描述:

  • 网络安全和各种加密的问题,包括Xss、国密、SQL注入等问题,国家安全数据规范的问题,第三方接口数据安全的问题
  • 数字建设第三方问题,包括常见的安全问题,比如信息泄漏、SQL注入、数据加密、逻辑漏洞、各个框架安全问题(比如log4j)、数据安全、文件上传等
  • 新技术框架的整合和融入,新技术的升级问题,兼容问题,新旧升级过渡问题,升级成本的问题考虑等
  • 云平台兼容适配的问题,包括国产操作系统、第三方云平台、私有云、IDC问题,CPU问题等
  • 前端兼容的问题,包括新前端兼容,浏览器兼容,移动端的兼容,接口的兼容问题,接口规范定义的问题
  • 数据库的兼容,包括国产数据库不同版本,数据库迁移的问题,第三方数据库,缓存的兼容问题,后期数据标准的问题
  • 新旧技术衔接问题,包括人员学习成本,学习案例成本,文档梳理成本,业务升级投入成本的问题
  • 数据采集成本的问题,包括业务数据来源的问题,数据规范不统一的问题,数据质量的问题,数据源不一致的问题,数据沉淀的问题
  • 数据与业务打通的问题,包括数据整合梳理提交流程,数据上传流程,业务数据共享的问题
  • 数据运营的问题,数据与业务整合计算的问题,数据反馈协助业务运营的问题,数据标准和资产管理问题
  • 运维监控的问题,这部分主要包括传统手工化运维、日志监控采集、,日志数据安全保留周期、异常信息预警、运行监控等;
  • 自动化版本管理业务集成的问题,这部分主要包括数据安全的处理、备份、定时巡检的处理、结果预警、自动扫描、安全巡检等。
  • …..

使用中台解决方案

这里主要考虑的是几部分,从封装,规避,服务几个角度进行阐述,大的指导方向是中台层建设封装,业务技术的卡点规避,中台层提供的服务,从职责上进去划分,主要包括如下:

中台层的封装

中台层的封装主要是规避底层的技术能力和内部的衔接,这里包括多个层面的基础层建设,这里使用了中台层的技术架构工具实现,输出成为基础的公用业务建设平台层能力,通用型的业务建设能力,规避和上一层能力的重复性。

数字中台提取出公共的业务服务,封闭统一的业务接口,为业务上层的集成,提供基础能力,让业务中台建设和业务组件集成,不需要再考虑底层的技术偏差问题,同时提供出源码型的交付,业务针对于自身的情况,提供出基础的中台服务。

研发中台产品架构图,结合团队/组织架构/数据/应用/运营整体体系的产品规划,整体产品架构图,这里主要输出的能力方向如下:

业务建设卡点的规避

中台层服务能力

这里服务能力包括几个方面,这里常见的列了几个常见的点,主要几个点:

  • 团队组织的服务能力,过程的建设指导能力
  • 过程中台能力的支撑解决服务能力
  • 技术架构的设计和业务整合的服务能力
  • 业务建设过程的文档输出和示例输出的服务能力

上面基本上是基础的团队型服务能力,这些基础的能力,解决了支撑体系的问题,但是在基础层输出另一层,即是实际的输出表现,这里主要体现的是产品能力:

  • 研发文档型的输出,这个是最直观性的
  • 接口和数据共享型的的输出,这个是直接的基础中台层能力
  • 工具型的可视化输出,这个是基础中台层的过程能力

在服务体系和直接产品型为基础提供了落地的保障,使更加站在业务型建设上进行的规划和思。基于以上的服务,进一步的推动业务建设,主要体现几个点:

  • 让业务建设专家专注于业务架构的输出
  • 业务团队专注于业务的建设和思考,更多的时间周期在业务的问题上
  • 提高业务创新水平和服务水平,提供业务质量水平
  • 更多的加强在客户关系维护和需求分析和落实上,提供更优质的客户服务
  • 更好的业务产品体验,在商务和市场上更高的抽取出来
  • 高层级的人员和管理者可以抽取,进行更多战略型的思考和发展

其它

  • 暂无

我基于开源和主流技术梳理的研发体系架构

此文章为技术输出章节,为中台技术支持体系的基础支撑架构方案和思路,主要面向中小型团队的支撑架构,大型或者超大型团队建议自建

概述

近几年常见的主流技术名词很多,主流新的方向也很多,比如DataOps、GitOps,DevOps、Scrum(敏捷)、ChatOps、PaaS、CloudNative(云原生)等多个主流的名词,当然还有其它领域的,比如GIS、SmaryCity(智慧城市)、元宇宙、数据中台等,这些主要听起来很高大上,确实很高大上,但是回到实际团队,这些又解决了我们什么痛点,价值性对自己有何作用点,体现在哪儿。

接触过一些团队,都有这些规划,也有这些实施的方向,走向也很明确,但是操作起来可能是另一回事。

基础能力

建设过程

后期扩展

其它

vuepress2.x文档和集成algolia配置过程

此为升级经验输出,主要针对于vuepress2.x集成algolia的过程

背景

文档和官网是acp输出能力的体现之一,原基于vuepress版本为0.x版本,中间做了部分升级,也走了一些问题点,这里同步做个记录。

集成找到资料比较多的方式是按vuepress官网提的使用邮件发送,然后回复,但是经过几次之后,发现周期慢,而且貌似最后也没有见key和index发到邮箱里面。

考虑左右,使用api文档上传的方式,但是vuepress集成的时候,algolia提供了相应的配置,同时可以集成github action进行提交,集成效果如下:

升级集成的仓库地址如下:

https://github.com/alinesno-cloud/alinesno-cloud-platform-press

集成思路

这里自己三种方式集成,这里做一下记录,主要是:

  • shell脚本集成
  • github action集成

Shell脚本集成

shell脚本集成是比较快速的,这里主要几个步骤:

  • 注册官网,获取到key和appid
  • 获取docsearch,配置config.json
  • vuepress集成验证

注册官网

官网地址是:https://www.algolia.com/ref/docsearch 按着步骤注册即可,同时生成应用和获取apikey,官网操作相对比较简单,这里就不过多阐述。

这里需要注意的一点是,index会自动生成,所以只需要key就可以(注意是admin-key)

获取docsearch配置

这里主要在linux上操作可能会比较简单,我这里是mac系统,windows的可以使用github action集成验证,这里是docsearch的下载地址:

https://github.com/algolia/docsearch-scraper

下载之后,生成config.json文件,注意新手尽量使用下面的config.json配置,之前也是验证了几个方式都不太顺利,如下:

{
  "index_name": "acp_linesno",
  "start_urls": [
    {
      "url": "http://alinesno-platform.linesno.com/",
      "selectors_key": "v2",
      "tags": [
        "v2"
      ]
    }
  ],
  "stop_urls": [],
  "selectors": {
    "v2": {
      "lvl0": {
        "selector": ".sidebar-heading.active",
        "global": true,
        "default_value": "Documentation"
      },
      "lvl1": ".theme-default-content h1",
      "lvl2": ".theme-default-content h2",
      "lvl3": ".theme-default-content h3",
      "lvl4": ".theme-default-content h4",
      "lvl5": ".theme-default-content h5",
      "text": ".theme-default-content p, .theme-default-content li",
      "lang": {
        "selector": "/html/@lang",
        "type": "xpath",
        "global": true
      }
    }
  },
  "scrape_start_urls": false,
  "strip_chars": " .,;:#",
  "custom_settings": {
    "attributesForFaceting": [
      "lang",
      "tags"
    ]
  }
}

其实algolia官网也有配置参考,上面是针对于v2版本做过调整,参考的config仓库是这个:

https://github.com/algolia/docsearch-configs

获取到配置之后,运行docsearch文件,第一次运行的时候,会提交让你填写appid和key,主要保存在.env文件里面,然后提交官网索引,生成效果如下:

./docsearch run ./config.json

生成之后,可以在官网的地址查看生成的索引情况,注意上面的应用选择和索引选择,如下:

官网提供了一个测试的办法,进行验证,如下:

./docsearch playground ./config.jso

会生成一个简单的测试界面,这里就不过多的粘贴。

vuepress集成验证

这里集成主要参考官网的链接就可,具体链接地址如下:

https://v2.vuepress.vuejs.org/zh/reference/plugin/docsearch.html

修改好apiid和key,下面是我的配置,也是参考vuepress2官方的:

appId: 'HAT6A1ER66',
apiKey: '1c5e0970f29dd7423d668b1fd245a7e2',
indexName: 'acp_linesno',
searchParameters: {
  facetFilters: ['tags:v2'],  # 注意这个地方
},

github action集成

这里主要参考基线的代码,这里就不做过多的阐述,主要集成的workflow.yaml文件可以从这里获取:

https://github.com/alinesno-cloud/alinesno-cloud-platform-press/blob/2.1.0/.github/workflows/docIndex.yaml

注意一点是,上面是创建了一个.algolia文件来进行配置。

其它

以下即集成algolia的教程,主要参考的资料地址如下:

  • 文件配置:https://github.com/algolia/docsearch-configs
  • 生成索引:https://github.com/algolia/docsearch-scraper
  • 文档配置:https://docsearch.algolia.com/docs/legacy/run-your-own/

我把传统业务架构升级到业务中台架构的心得

此为实战经验输出章节,重点在于自我的经验总结和实践经验记录,自己在整个过程角色是架构师和研发部门负责人角色,即设计和执行合一。

背景

开始介入的时候已经基本上完成一版本,部署和架构基于传统的服务化方案,进行RPC之间调用,服务器和监控的模式还是传统的虚拟机资源分配的形式,项目管理按传统的软件工程管理进行。项目的规模属于中型项目,政务民生类项目,用户规模大概在城市级百万级左右,每天涉及到资金交易在亿级别,项目周期大概是1年多,属于业务型服务。

以下阐述规避涉密因素不涉及相关单位和公司字眼。

概述

从传统业务架构的服务器发布,同时也包括项目管理开发流程(CMMI5结构),再到传统的项目管理运维等进行架构升级,升级的目标为业务中台架构,为下一步数据运营管理做好基础。升级过程从团队、专家、业务、架构等几个维护进行的调整,以适应当前IT行业的发展和数字化市场环境,在这个升级的过程不仅仅是技术项目的升级,更多的是组织架构,团队技能的升级,以消除前期传统模式留下的弊端。

升级过程阐述分三个维护,主要升级的成果点:

  • 传统系统架构升级中台系统架构模式,即提取业务中台,大中台,小前台模式;
  • 管理模式转换成中台组织架构模式,即中台专家支持,业务兵团走前端;
  • 软件项目开发转换成行业产品型研发,即输出项目的同时输出中台产品型服务;
  • 传统的运维模式升级成自动化运维模式,即全方面的运维监控体系,可自动化可预警;

按前期-中期-后期三个时间段时间编写,整个过程我有我思。

升级过程

这个过程无疑还是一个突出的问题:决心。中台型的转变需要整体团队的互相配合。每个节点做好自己的事情,需要上下一心的转变,领导层的意识和可行性的架构能力的支撑。

过程基本是老打法、老方式,而这也是最有效的。

前期

前期最主要的还是团队的意识,这里的团队包括的不仅仅是一个组,而是整个团队的上下意识,这个过程调整了组织结构,这基本上将原有的项目管理模式归由研发部进行整体指导,主要是:

  • 调整组织结构,技术支撑下沉到研发部,由我这边进行统筹;
  • 技术架构重构,进行二次架构的升级,形成全体升级转变的指导思想;
  • 将升级战略上升到团队最高层面,思想意识统一;

以上两步基本上解决了执行的基础保障,也是中台架构的基础保障条件。

架构升级的前期遇到的最突出的问题,旧系统的切换,这是一个矛盾点,在不违背大家过大的意愿下,调整的架构设计,当中也做了很多妥协,另一个是牺牲一部分技术妥协团队的接受,一步步推进。从上而下的业务模式改变,主要包括几个点:

  • 虚拟机转变成k8s容器化,升级虚拟机配置,减少服务器数量;
  • 发布过程集成docker容器化,同时调整最小配置,减少大家的学习成本;
  • 流量的切入转换成对外nodeport的形式(rpc协议),这是一个妥协点,主要还是考虑到技术的过度;
  • 服务化设计保留原来的基础工程结构,保留前期的CICD还有服务调用模式。

上面几步基本上解决了基础层的问题点,还有过程持续构建的弊端点,资源不稳定点等。

中前期

基础层的解决和保障,最终还是回到业务建设上。

最可能出现问题的一点和沉淀能力的抽取考虑上,原业务架构,比如原来就没有考虑到这样的方式,进行的项目还有工程研发等,这个基本上最有可能导致后期上线不稳定的因素,做了几点:

  • 培养和完善手册,还有培训机制,将各个责任点下放;
  • 保留原服务工程的调用机制,尽量在k8s上进行妥协和解决问题,实在不行的再调整业务代码;
  • 完善运维机制和监控机制,原有的业务排查方式和发布式的转变;
  • 多层面上进行运维角度的整合,包括系统、日志、链路、流量、灰度等多个层面的保障;
  • 去掉一些不可控的业务节点,保留原运行模式,规避各类安全策略的问题,这也是一个妥协点。
  • 业务服务抽取可形成产品模块,此从业务层面进行妥协,调整代码和项目结构;
  • 多处运用消息机制,进行业务模块的解耦和可产品化调整,此也从业务层面上进行妥协。

基于以上多种结构的调整,基本上业务中台架构的雏形很快体现,这个过程消耗了差不多几个月的时间,基本上还是符合预期点,在有项目的推进下,其实各个部门还有项目组基本上感知性还有排斥性没有多大的体现,在研发和技术的支撑上,转变过程基本上无感知。

中期

这是一个问题暴露阶段,这个过程需要的全员的配合,这也是为什么在前期下放责任和思想 统一的原因点,一个架构师,一个部门是无法支撑起团队能力的。

过程问题最突出的一个体现:信心问题。这个是前期自己的问题点,当然,这也是在自己把控范围内的一点,也是必然会出现的一个情况,这个跟以前转型(自己在多家大中型团队做过转型)基本上是一模一样的问题体现,有的时候,在理论上是可避免的,但是在操作上却是不可避免的。

初期的验证和转换调整操作,基本上觉得没什么问题,但现实是不可预知的,在综合业务场景上并不等同于互联网型的通用项目,行业软件存在很多不一样的因素,它里面包含了很多复杂的业务逻辑,类似于银行系统,并不是那么敢轻易换掉oracle一样。当前项目也涉及到大量的资金交易也较大。在上线暴露问题点的同时,很多找到的解决方案都没有涉及到,这步让团队在切入过程中,心态上比较紧张,对新架构的信心程度还有各个节点的支撑人员也头疼。

一个场景是在前期基本上按k8s服务之间调用方式来进行的,但是在内外网络隔离,还有外围服务的时候,IP判断的问题,还有各种第三方插件的问题等,还有各个使用群体(比如银行)上相应表现不佳。沟通协调,排查困难程度较大,单个层面无法解决,最终是上下层统一协调解决点。

类似于上面的场景,并不是说有多大困难,而是部分场景下没有思路,各种条件下问题比较隐性。这个过程是团队会面对的问题,在最终解决下,会更进一步的提升团队的能力点,最终达到内部接受到自然状态。

另一个是一些操作的不成熟,还有验证性,需要大量的生产和测试验证,以确保可行性和后期的稳定性,这些前期验证环境有操作,但是也有很多未知,这些都是要面对克服的问题,这个过程几乎都是熬夜过来(几乎每次转型都遇到类似),同样需要整体团队的解决能力。

后期

这里针对的是在架构设计层支撑和中台研发团队架构的支撑上的后期。

到这一步的时候,业务中台架构基本上便向于稳定,由原来的中台架构雏形,转变成业务中台架构。不管是技术、团队、业务、专家还有各个场景下的沉淀都已经有了沉淀能力,包括解决方案等,形成一套业务中台能力点,主要包括以下几个点:

  • 团队组织能力,形成中台组织架构保障,研发层和业务层;
  • 技术沉淀能力,形成技术中台和研发支撑层;
  • 产品输出能力,形成行业产品沉淀,形成基础的行业标准产品组件;
  • 解决方案能力,在行业软件中形成一套可行的解决方案;
  • 中台业务能力,业务大中台产出,小前台业务建设的综合能力。

余下的,更多的是架构设计的前期问题梳理和进一步的优化,各个管理功能的完善和进一步沉淀产品能力,集成到中台管理平台上,同时在各个团队和小组之间进行经验分享和总结。同时为下一个业务场景进行梳理。

其它

按目前的行业发展来看,当前AI、物联网等智能化的发展迅速,在进一步待场景和人才,目前也在整合这些能力点,在业务中台化建设的后期,同样会在中台化的基础上融入AI、物联网的基础产品能力范围,在行业中台上面进一步的升级业务中台大脑。