对基于云原生解决方案的技术中台产品规划和架构思考

　　今天谈下基于云原生的技术中台产品规划方面的思考。自己在前面也写了很多关于SOA，中台，DevOps和云原生的相关技术文章。在这些文章里面也谈了技术中台或传统我们谈的私有云PaaS技术平台，而云原生解决方案的核心是SOA+DevOps+容器云技术的融合，因此今天重点是谈围绕这三个核心点的技术中台规划。IT架构转型和软件发展趋势分析
　　在谈具体的规划和架构设计前，我们也先看下当前整体的软件发展趋势。
　　1.中台之战-软件企业也需快速转型
　　最近我谈企业中台的文章比较多，但是更多的是从甲方企业的视角来思考如何规划建设企业中台，包括里面的业务中台和数据中台。而对于软件企业，我们原来会讲有技术平台积累的软件企业往往会领先一步，实现更高的开发效率和质量；而从趋势来看我们现在可以说，深度耕耘在某一个垂直业务领域，并积累了业务中台和数据中台的软件企业会胜出。
　　业务中台是企业针对某一个业务领域的业务系统在经过了大量项目建设实施，业务流程分析和业务梳理后进行的业务模型抽象，因此业务中台将具备面向多数企业的业务模型和业务能力可复用的普适性。
　　传统方式下我们可能是20%的平台，80%的定制开发。而新模式则是80%的平台+中台，20%定制开发。
　　一个业务领域的软件产品能够做到上述模式，即使没有完全的产品化我们也不怕，我们也可以快速的完成面向客户业务流程和业务场景的快速实施交付。而且我们底层的业务模型是稳定的，是可持续优化的。
　　相反，完全产品化的产品反而无法真正适应快速变化的前台业务模式和业务场景。
　　因此以后的软件企业之争不再是平台之战，而是中台之战，这句话对甲方和乙方软件企业都适合。
　　2.开放之战-从能力开放到生态体系建设
　　对于第二点我想谈下软件企业的能力开放，要明白整个IT和互联网的发展趋势就是开放互赢，通过开放形成更多的连接，通过连接和协同来满足更多的业务场景和需求。通过能力开放可以方便我们更好的连接上下游的各种资源，提供整合后的更加强大的服务能力。
　　开放还有一个潜台词就是企业只关注自己的核心能力和价值的实现，只专注在自己的专业垂直细分领域，而不要做去大而全的东西。真正的大而全是通过能力开放后，通过大生态系统准备演进和整合出来的。通过开放我们一方便可以更好的适应外在的变化，同时有可能让我们更加专注在自身专业能力的积累上。
　　一个企业从最简单的接口能力开放，还可以逐步去主导和运营一个生态体系，一个整合了各种资源能力的好的生态体系往往能够为客户提供更多有价值的产品和服务。
　　有了开放就有了连接，有了连接就有了相互依存，而相互依存是能够合作共赢的基础。
　　3.从消费互联到产业互联
　　谈数字化转型一定会谈到企业信息化的发展整个过程，从企业内部的信息化发展到消费互联网，再到现在我们谈的比较多的产业互联网。正是这种发展可以看到连接的范围，连接的类型都做了很大的扩展。只有有了连接才可能产生数据，有了连接才能够形成协同。
　　互联的一个核心就是连接，只有连接才能够产生数据。
　　而在整个连接里面我们看到本身又分了几个阶段，从最早的企业内部的各个业务单元的连接，企业内部的三流协同，再到企业到消费者的连接和直接触达，再到企业整个供应链的连接和产业协同。连接里面有另外一个重点就是直接触达，减少中间环节，这个也是需要重点能够呈现的内容。
　　基于以上思考，整个构图需要能够展现从企业内部信息化到消费互联，到产业互联的全连接，通过构图能够呈现这种边界上的差异，通过构图能够呈现整个互联协同和中间环节上的差异，如下图：
　　4. 万物互联是整体发展大趋势
　　最后谈下万物互联，实际上对于万物互联在前面已经有很多文章都谈到，设备和设备的连接，设备和人的连接，人和人的连接，生态提出中各个参与方的连接，硬件和软件的连接，应用和内容的连接，操作类业务和分析型业务的连接，本地局域网和互联网，5G网络的连接都可以纳入到万物互联中来。
　　在万物互联下我们看到，原来的边界反而是越来越弱化了，这里面典型的就是硬件和软件的边界，软件应用和软件内容的边界，云计算的边界（云计算到边缘计算），也可以讲在万物互联的思路下整体是去边界化的。
　　因此对于软件企业也要意识到不要自己给自己加一个约束和边界，而是应该去拥抱变化。
　　就拿我们公司来说，在万物互联思路下，我们当前的云计算平台，我们的技术平台，我们的SOA总线，我们的电商平台等都需要进一步去优化和升级，去真正覆盖万物，连接万物，同时实现对硬件和软件的整合和协同。包括传统的物联网平台，在真正融入了软件平台和业务场景后就成为了一个物联网业务生态聚合平台。对咨询+产品+实施三者的方向选择
　　对于围绕云原生的解决方案，在前面我曾经谈到过包括了技术规划咨询，产品，实施三个方面的内容。你可以规划一个端到端的全流程解决方案，也可以根据当前资源情况侧重于某一个方面的技术能力实现。
　　IT规划和咨询类项目的取舍
　　对于公司和产品线来说，最近我们很少做单独的IT规划和咨询类项目，对于原因在前面我分析过，具体包括如下几个方面的考虑。
　　首先就是咨询类项目本质是很难做到产品化和规模性复制，即完全是靠的人天工作量的堆积。也正是这个原因我们可以看到对于咨询类公司要做到扩大营收和盈利，必须是不断的扩展团队规模才可能。
　　对于软件类项目，虽然我们也在做定制和实施，但是我们的报价体系本身已经变成了产品费用+实施费用，即我们沉淀下的产品本身已经可以卖钱，但是对于咨询类项目，你很难说你沉淀下的知识库能够给客户先算一笔钱，客户仍然会是按照你投入的人天工作量进行算钱。即使你人天单价报的再高，实际上整个价值创造仍然是存在明细的天花板。
　　正如一个独立的培训老师，你最大的价值和盈利无外乎就是250个工作日天天在外面培训和上课。
　　其次，咨询类项目往往对单个人员有更高的资质要求。对于咨询类项目如果要做好，往往必须是安排整个团队里面的核心项目经理和核心顾问往往才具备这个能力，而这些人一投入到咨询类项目后往往就无法兼顾其它建设实施类项目，这样导致我们其它项目建设和实施往往很难管控好，或者说我们会出现很大中低技能的团队成员没有人带的情况，这也是整个团队在资源规划和统筹的时候不允许出现的问题。
　　今年我们又拒绝了几个IT规划咨询类项目，后面反思下这种决策还是合理的，这种咨询项目完全依赖的是1到2个核心人员的能力而无法真正发挥团队的大兵团作战。
　　对于很多咨询项目，我们经常也在想着通过咨询类项目切入，然后再将我们的IT系统建设类项目带入，逐步扩展在企业的市场，但是这种方式真正成功的没有几个，一个就是咨询期和建设期本身在很多企业不是完全连续的，其次就是建设期往往是其它部门或领导在决策，你虽然做过咨询也不一定能占多大优势。因此这种咨询类项目的提前投入，必须是有很强的市场关系背书往往才真正可行。
　　企业中台建设的提速
　　在上一篇文章我摘录了南方电网2020年的泛在电力物联网建设规划任务，里面明确提出了建设企业中台，包括了数据中台和客户服务和资源服务的业务中台。由于我们经常做电信运营商的项目，对于几个运营商来说也是明确提出了建设业务中台，技术中台，数据中台和AI中台的概念。
　　因此可以看到企业中台架构和从传统架构朝微服务架构转型将成为2020年很多企业IT建设的一个重点方向，其中既包括了IT架构转型咨询规划，也包括了实际的中台基础技术能力建设和业务能力，支撑能力建设等多个部分的内容。而从年初我们就在规划我们的DevOps整体解决方案。
　　其中包括了微服务架构咨询规划，研发过程支撑，DevOps支撑平台和API网关，这些刚好形成一个完整的围绕中台建设的支撑能力平台的整体。有了这个基础能力建设，企业可以更加方便的进行上层各个中台微服务模块的建设。而在这个推进过程中，本身又存在两种策略。其一：强规划咨询方式+平台+实施落地其二：弱咨询，仅仅建设实施DevOps支撑平台+API网关能力开放体系
　　对于方式一是很多企业实际需要的方式，即很多企业本身并没有理清楚如何拆分中台模块，中台究竟应该建设哪些中心，原有的遗留IT系统究竟应该按照什么顺序一步步的迁移到新的IT架构上面来。但是方式一本身也可以看到又是一种强咨询的方式，需要我们投入大量的核心顾问人力往往项目才能够顺利开展和落地。
　　而如果一个企业本身就有很强的IT团队和业务积累，特别是那些本身就是流程+IT统一管理的大企业，实际上我们完全可以推广方式二，弱化前期的业务规划咨询，而仅仅推广实施技术平台。这种方式往往可以快速的实现我们技术平台的推广和实施效果。
　　对于甲方企业来说信息化建设以后就是中台能力之战，而对于乙方软件企业来说以后的软件系统开发和实施本身也是中台能力之战。甲方围绕中台实现快速敏捷响应业务，乙方基于中台积累实现能力复用和产品规模化复制，这正是甲乙双方都需要的关键内容。产品持续迭代和持续稳定现金流
　　在前面我们谈到了两种推进方式，一种是强规划咨询切入，一种丝毫弱规划咨询而是以产品化的方式推进和切入。在这两种发展思路里面，实际上我更偏向于第二种弱咨询的方式，因为这种方式可以更好的按产品化的思路推进，同时又可以最大限度的控制主团队规模，要明白团队规模的控制本身就是最好的一种利润最大化又抵御风险的方式。
　　但是按现在大部分企业的信息化建设水平来说，仍然是相当的落后，信息化已有的积累很弱，本身传统IT架构都还没有实施好更谈不上转型。即使是转型，本身对新业务，新技术的思考和理解也存在很大的偏差。也就是说，没有很强的规划咨询，包括对企业研发文化的重塑，你的平台建设很难在企业真正落地和推广。
　　因此实际上更好的思路在前期仍然是咨询规划和强实施切入，然后对这部分内容进一步的产品化和服务化。要意识到软件可以产品化，那么咨询规划本身也可以产品化和服务化。
　　产品，项目和现金流
　　回顾下我们整个19年的产品规划和实际落地情况来看，实际上真正落地的在60%左右，这个效果感觉还算不错，不错的原因是在利用团队资源空闲的时间来做了这个事情，最大限度控制了成本。
　　一说到产品规划，绕不开的就是产品前期研发资源投入和成本的问题，每次做产品规划我们都会做SWOT分析，都会做ROI测算，但是规划完成的产品无法真正卖出去，没有孵化成功的情况也是经常的。一个产品研发完成没有市场，卖不出去，不能形成收益回补完成自我造血功能，那么产品夭折是迟早的事情。
　　原来我们也会谈基于项目来孵化产品，这种方式最好的思路就是不需要单独的产品研发成本投入，成本费用包括在了项目中，但是缺点也很明显，项目明显带了客户的定制化，导致有时候抽象和剥离标准产品变得很困难，或者说根本就无法通过项目的产出直接形成一个我们理想的标准化产品。
　　对于软件企业来说，这一两年日子并不太好过，相信2020年也会是苦日子，在这种场景下往往生存下去，活下来才是第一位的。因此现金流至关重要，产品能够卖出去形成稳定持续盈利至关重要，你所有的产品规划仍然必须围绕企业经营来展开。
　　因此项目是否一定能产品化不是最重要的，项目能否持续并稳定盈利才是最重要的。
　　那么在产品规划上面，我们需要考虑两点
　　其一是产品最小化迭代完成自我造血能力：一个产品如果不能通过最小化的投入来完成面向客户的迭代版本并实现自我造血能力，那么这个产品在当前的形势下就不是一个好的产品。我们在产品规划上面可以试错，但是这个代价必须可控，我们的退出机制必须要完善。
　　其二是产品整个研发周期要匹配市场机会来敏捷响应和投入：比如当前某一个产品我们分析有一定的市场需求和机会，那么我们是先提前全部投入将这个产品全部研发出来呢？还是实际上我们会先形成各种可组装的半成品等待机会出现？要知道一个市场需求的真正落地本身也有一个周期，而我们本身的产品研发投入也完全可以更加灵活的去匹配这个周期，以控制风险。
　　异地多团队协同研发模式的完善
　　最近几年大家看到比较多的就是一线城市的软件企业，很大研发超类似武汉，西安，成都等城市的转移，分别在这些地方建立研发中心或者研究院。一线城市的研发人力成本问题当前已经严重影响到软件企业本身的经营乃至生存，战略性的转移也势在必行。
　　而这种转移带来的一定就是跨地域的多团队研发协同，这种协同和当前主流的微服务架构，组件化和模块化拆分本身也是相匹配的，同时也和我们推广的DevOps平台匹配的。异地协同必须有相应的组织，架构，团队上面的转变，也一定会需要研发支撑过程和工具上面的转变。
　　而我们说的支撑包括了研发过程管理，持续集成和交付，测试和环境管理多方面，同时这些支撑能力完全可以构建在公有云平台上来完成。也就是说异地团队来说，团队唯一需要的就是一个办公场所和个人的研发笔记本电脑即可以完成异地开发协同工作，人究竟在哪里已经不重要。
　　在2020年我们规划还是要进一步完善异地开发团队构建和协同上的实践，这个实践刚好也是我们对微服务架构，对DevOps支撑过程的一次全面自我实践。围绕云原生技术中台规划
　　在上面的架构图里面可以看到，实际上整个平台包括两个大的部分，一个是DevOps支撑平台，一个是API能力开放平台（包括了API网关）。而两个平台的开发和运行本身又是基于微服务架构开发框架和模式进行。因此在实际的产品规划和发展中，重心仍然是围绕以上两个平台展开。
　　API能力开放平台
　　这个在原来博客文章里面已经谈到，整个思路还是基于Kong网关进行二次开发和定制，远期规划思路是基于Go语言来完全自主实现API网关。
　　对于API能力开放平台，简单来说底层是Kong的API网关，中间是API管控治理平台实现API全生命周期管理能力，上层为API运营平台。其中API全生命周期管理平台又包括了API的开发和快速接入，发布平台；API的实际管控治理平台，API的运行监控，运维平台。
　　对于Kong网关的实际定制开发，主要是加强网关的安全，日志，限流熔断，服务接入消费自服务，权限隔离几个方面的关键能力。实际上我们看到Kong网关本身的协议转化适配，数据映射等能力是偏弱的，那在使用Kong网关接入的时候还是需要进一步增加协议转换适配方面的能力。
　　简单来说Kong网关可以统一发布Http Rest API的接口服务。
　　但是我们需要在Kong网关上增加相应的协议转换类插件来支撑遗留的接口快速发布，其中主要包括了将数据库标或SQL直接发布为Rest接口，将传统的SOAP WS直接发布为Rest API接口，将JMS消息适配后发布为Http Rest接口。支持这几种后基本可以满足我们日常大部分需求。
　　其次，需要增强基于Kong网关的管控治理能力，其中包括了我们常见的服务授权，安全配置，日志查看，限流配置，服务快速接入等。同时也包括了服务运行监控部分，对于服务运行监控完全可以参考我们当前ESB总线的思路来进行实现接口。
　　对于是否有配合Kong网关使用的服务链监控工具，限流熔断工具，需要进一步研究。
　　最后，对于API能力运营平台，这个优先级应该比较低，我们的重点还是优先放在平台层能力，管控能力的完善，然后再来考虑服务运营方面能力的完善。服务本身也是商品，因此服务运营平台的底层核心逻辑仍然是电商平台的核心模型，这是我们可以参考和借鉴的地方。
　　DevOps支撑平台和容器化PaaS平台
　　不管是API能力开放平台还是API网关，可以看到实际上并没有想象的容易推广。这主要有几个方面的原因，其一是很多企业还在传统IT架构下没有转型，本身就没有场景用到API网关；其二是企业虽然用到微服务架构或Rest API接口，但是业务量小接口少，没有到需要对接口进行统一管控治理的程度；其三就是对于大型一点的企业一般有自己的独立开发团队，开发团队能够进行微服务架构转型，自然也能够采用开源的API网关自己进行定制，而不需要再单独购买服务。
　　因此API网关的推广策略不是简单推广一个工具平台，而是需要配合我们微服务架构咨询，IT架构转型咨询一起推广实施才真正有效果。
　　另外一个推广策略就是API网关作为我们整个DevOps支撑平台整体解决方案里面的一个子系统，然后整体面向大型企业客户，大型开发团队进行推广实施，形成一个相互配合的完整解决方案。
　　对于DevOps支撑平台实际上要完善的地方很多，在这里我还是把他划分为几个大的部分。研发过程管理持续集成和交付平台API网关容器化PaaS平台+其它技术服务类平台运维监控平台
　　在研发过程管理中主要是参考Scrum敏捷方法论的思路来实现以需求和用户故事为主线的整个研发生命周期管理，认为跟踪和监控，实现完整需求闭环和团队协同管理。在持续集成和交付平台，重点提示测试管理能力，或者你可以理解为这里需要一个完整的测试平台，覆盖测试用例，数据管理，测试执行，测试结果分析全生命周期管理能力。其次是技术服务类平台，这个各个企业有差异，但是我们需要支持这种标准能力接入和管理。
　　对于运维监控平台一直是需要整合和完善的地方，这里的运维包括了自动化运维流程标准的完善，运维流程和持续集成过程的协同；这里的监控包括了资源监控和服务监控，日志监控查询多个方面，而服务监控的重点又在服务链监控上面。
　　企业全面上云和朝云端迁移将成为趋势
　　首先我们来看下最近几年的一个关键概念云原生，美国专注于云计算与大数据基础平台的公司Pivotal最先提出了云原生应用，后来由谷歌成立的云原生计算基金会（CNCF，全称Cloud Native Computing Foundation）对云原生应用进行了定义，即：
　　云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术让工程师能够轻松地对系统作出频繁和可预测的重大变更。
　　简单来说，云原生可以从字面涵义来理解，指的是任何在云中诞生、或主要在云中设计并运行的事物。但云原生不只是指应用程序所在的位置，更多的是指应用程序的的构建和部署方式。
　　我们可以看下企业软件开发的一个发展阶段，简单点梳理可以为：企业的应用软件开发，设计，环境运行全部在公司内部私有云环境和数据中心软件开发，设计，测试等在企业内部，但是最终部署在公有云环境运行软件的开发，设计，测试，整个构建和部署，持续集成过程全部在公有云环境进行
　　到了第二阶段企业不用购买生产环境服务器资源，到了第三阶段企业应该不再购买任何的服务器资源，所有的开发，测试，生产全部迁移到云环境进行。对于完全轻资产运作的企业往往可以完全采用全云化的思路，而对于生产制造类型的企业类似ERP和MES等大型系统不适合全部迁移到云端，但是完全可以采用混合云的架构模式。
　　云原生的核心目标是将企业IT应用和IT基础设施的部署变得更加敏捷，从而使企业能够采用较低的技术成本享受到云的弹性和灵活性。根据云原生计算基金会(CNCF)的最初定义，云原生包括了：容器化封装+自动化管理+面向微服务。到了2018年，CNCF又将服务网格(Service Mesh)和声明式API给加了进来。具体而言，容器技术，服务网格，微服务和Serverless是云原生的核心技术，而DevOps是对这些技术进行整合的一个关键实践。
　　而云原生的关键优势主要包括：与传统的单体应用程序相比，由于使用敏捷和DevOps流程进行迭代，加快了产品上市微服务架构下自动地逐步改进云原生应用程序，以不断添加新功能或者改进原有功能。可以非侵入式地进行改进，不会造成停机或中断服务，给用户造成不良体验。支持云原生应用程序的基础架构弹性良好，可以轻松进行拓展或缩小规模。云原生开发流程可以更好地适应当今业务环境所需的速度和创新。
　　具体参考：https://www.secpulse.com/archives/118893.html
　　因此我们看到企业全面上云和朝云端迁移将成为趋势，而这里面云原生的优势也会逐步体现出来，而整个迁移和转型里面恰好也是我们当前重点在建设和研发的微服务架构，DevOps支撑平台。技术中台子系统规划
　　最后再对IT架构转型过程中，我们提供的平台化产品体系进行下梳理，重点还是要搞清楚里面会涉及到哪些子系统，以及这些子系统间关键的集成关系等。
　　敏捷研发管理子系统：这个基于scrum敏捷方法论来实现最基本的敏捷研发过程管理，核心对象为需求，产品，项目，版本，任务，团队，日志，缺陷，变更等，实现最基本的研发过程管理。
　　DevOps支撑平台：核心是实现持续集成和持续交付能力，同时在支撑平台中实现环境管理，配置管理，测试管理和自动化测试，流水线设计编排等关键能力。
　　容器化PaaS平台：单独拿出来形成一个子系统，核心是Docker+kubernates调度平台，实现容器化的中间件资源池，资源的动态分配和调度，中间件集群等。
　　监控运维平台：核心是实现中间件资源的监控，服务和服务链的监控，问题的发现和自动化运维流程。当然这里也很可能会拆分为两个独立的子系统，一个是监控系统，一个是运维系统。监控发现的问题会进入到运维系统，当然用户反馈的问题也可以进入到运维系统。
　　技术服务平台：核心的技术服务能力实现，包括了流程，缓存，消息，文件存储等。该技术服务平台是要企业大应用大PaaS的必须部分，但是在前期我们整体架构中可以不用太关心。
　　API服务网关：原来在微服务架构开发框架中本身就包含，我们现在将其提出来形成独立的API网关子系统，同时在网关子系统中整合服务注册中心，服务链监控，服务限流熔断等关键能力。
　　门户和4A平台：在构建要应用架构体系的时候是必须的，实现底层业务模块组件的整合，在我们整个大PaaS思路里面应该包括这个内容。
　　服务运营平台：在整个能力开放平台大架构中需要，即将API网关聚合后的API服务能力作为商品进行运营，涉及到服务的订购，消费，服务计费，服务接入流程等相关内容。
　　实际上我们看到以上整体的平台架构规划和我们多年前的私有云PaaS平台架构规划相当类似，只是PaaS平台替换为了容器化的PaaS平台，ESB总线替换为了轻量的API网关，内部的PaaS门户替换为了服务运营服务平台。同时在整个研发生命周期中引入了DevOps支撑集成和持续交付方法论，引入了敏捷研发管理平台和工具。
　　对于以上子系统我们也可以看到，根据当前产品成熟度来划分如下：产品成熟度高并实践案例：DevOps支撑平台和容器化PaaS平台，门户和4A平台产品完成实践中：API网关，技术服务平台产品规划和设计阶段：研发管理平台，服务运营平台，监控运维平台
　　对于研发管理平台我们当前主要使用禅道来进行管理，整体和DevOps支撑平台还存在需要协同和集成的地方。同时对于API网关已经完成初步产品研发准备推广，而对于服务运营，运维监控平台相对来说比较弱。