构建技术中台——新技术验证与应用

2020年，普元基于自身技术中台所需，验证了一些新技术并加以使用，旨在不断提升技术中台的综合能力。通过这次机会，将我们团队所做的一些技术验证和使用方式与大家分享，希望在公司内外建立更好的技术沟通，同时提出技术中台的下一步发展想法，供大家参考指正。

 

1、介绍普元技术中台的现状

首先来看看我们现在中台的一个大概的情况。从下往上看的话，以基础设施开始，到容器云&中间件平台，再往上有两个平台，一个是运行&集成平台，用于支撑微服务、元数据、流程引擎等一系列的基础架构；另一个是效率&精益的平台，即DevOps，用于解决自动化测试、持续构建、自动部署等，再往上则根据行业去积累相关的业务组件。从图上可以看到，现在圈出来的这一部分，就是在普元定位出来的技术中台的一个全景。

容器云&中间件平台，最下面有一层集中式的调度、分发、监控、预警，这个是所有的中间件以及上层的应用需要的一个必备能力，接着也会在容器云中去建设像缓存消息、队列、数据库，NOSQL这一系列。

 

运行&集成平台上，我们分了两块，一块是应用，这里面以微服务作为支撑，用BPS等做流程集成、用ESB做API集成。再上面是跨端工具。还有一块是数据，以元数据为基础，数据质量稽核、数据的交换，数据的分析、数据的服务、数据的展示等这一系列数据全生命周期管理。

效率&精益平台，更多的瞄向从项目立项，需求任务缺陷等这一系列的管理到代码分支标签、到持续集成、到自动发布，再到后续的整体运维。 

2、分享2020年新验证使用的一些技术

2020年的新技术使用，整体上是这样的：主要分为三类：框架类、工具类、平台类。可能大家理解平台类和框架类好像有点类似，之所以叫平台类，我们认为这些东西可能当一个第三方的平台去参考或者去应用，而不是把它纳管到我们自己的内部的一个产品体系。还有一些之所以放在平台类，是因为我们更多是做了一些验证，还没有跟我们的东西完全集成在一起。分开来看看到底为什么要选择这些，用它来解决什么问题？

框架类

第一个istio， istio是用于解决在spring cloud架构下，像ribbon、netflix等流量管理，无法去解决其他语言的一些情况。因为它只面向于spring cloud，对其他架构、语言的系统无法统一管控。如果针对这些系统要去做流量治理时，则需要引入像istio这样的三方组件，使得我们其实是可以跨系统跨语言形成服务治理。 

所谓的服务治理，主要是熔断、限流、流量的分发、负载均衡等这一系列的需求。istio目前是部署在我们容器云平台里的。

第二个其实是spring cloud的K8s。大家在用spring cloud时，如果同时引入容器云的时候，往往会有很多的纠结点。比如说所有的服务进程，既注册在Eureka，或者Nacos上面，同样在容器云里，所有的服务都在ETCD上去注册了，这个时候我们到底应该以谁为准？ 

再一个例子，SpringConfig做配置管理，但是其实在容器云下有自己的configmap做配置管理，或者说负载均衡ribbon的情况下，到底我们去调用其他的服务的时候，是走k8s service，还是直接调他所有的pods，其实都是大家很纠结的点。 

早期我们也很纠结这样的一些问题，自从spring cloud生态中引入了springcloud K8s这样的组件，问题则迎刃而解。

 

现在做到了开发的时候，你不用关心底层基础设施，然后在打包的时候通过不同的依赖，使得在使用不同的基础设施的时候，实际运行的介质不一样，是我们对spring cloud k8s的验证和使用情况。

第三个是flink。熟悉普元的话，都知道我们更多的在数据这一层做的批数据，从数据集层到贴源层，然后再做标准化，做治理，再到主题库，打标签等等，最终支撑数据应用，做数据的服务化或展示。 

但是我们对于实时的或者准实时的数据采集加工，校验计算，发布订阅，之前并没有做太多的支撑。在今年我们做了flink预研，用来帮我们解决流式数据问题，最终流一体，支撑数据全生命周期管控。

工具类

工具类里首先是neo4j，一种图数据库。我们有两个场景需要使用，第一个是元数据产品，元数据产品最简单的功能是采集数据库有多少张表，一个表里有多少列等，还有这些数据之间的一系列关系，以前我们用传统的关系数据库去存储这样的关系的，当到了一定数据量的时候，自然这块就会出现了瓶颈，所以接着我们把元数据中关系信息存储到了图数据库，很大程度解决了性能瓶颈。

第二个场景则是知识图谱。举个例子，我们都知道东成西就的演员有梁朝伟、张家辉，我们这个时候如果想知道他俩有合作过其他的什么电影呢？这个时候就涉及到不是一个简单的人跟电影的关系了，涉及到多个人跟多部电影的关系，类似于这样的知识图谱场景，是我们要用neo4j的另一个场景。

当然使用neo4j也遗留了一些问题，因为大家知道neo4j的社区版跟商业版是不同的。商业版是收费的，如果用社区版的话,要解决可靠性问题，目前我们只能考虑冷备。另一个neo4j被诟病的批量插入性能问题，因为这两个场景并不涉及到海量数据的一次性插入，所以这个不是我们的主要瓶颈。

第二个工具有点杂，或者说不是单个工具，因为普元以前的话更多的插件是围绕着Eclipse去做插件开发的，而现在vscode、idea这样的一些插件成为了很多人的偏好。 

其实在2019年开始到现在2020年，我们已经讲很多的插件体系在保留原有的一个eclipse的同时，去做了其他工具的补充。比如在vscode上我们支持了面向于移动类的快速开发插件，idea上我们做了个人工作项查看插件。

再一个工具是k9s，运维的同学可能更熟悉一些，k8s的使用如get pod，get service这样的一些命令，在k9s上则可以使用类似字符终端模式来交互。

平台类

平台类的新技术运营，主要是借助补强了我们一些解决方案。

第一个是fisco。因为普元有像数据交换，资源目录这样的平台，在国家一些文件要求下，我们要去回答，什么样的数据要上链，上什么链（私链也有公链，也有联盟链）等问题， 所以我们在做一些技术选型和厂商适配。 

像百度、京东、华为像蚂蚁，他们都会提供他的一些链的服务，假设客户选择了这些链，或者说联盟链，我们也会去把我们的产品去做兼容性适配。我们目前在fisco这一层，其实主要是瞄向于政务口的，金融口上我们其实并没有做太多的应用。

第二块是datax，我们其实并没有用datax，之所以研究datax，是因为我们有一个跟datax类似的一个产品——DI（基于kettle）。kettle是一个优秀的etl工具，但是扩展的时候，其实会有一些难度。参照datax对于writer和reader的扩展，我们致力于让DI的扩展更简单。 

再一个其实是性能的问题，我们关注了datax性能到底怎么样，比如数据在交换的时候，尝试分批去做，这个在kettle也做得到，但是我们之前并没有把这个做成标准化的模板，这是我们在学习datax的思路后，重点想解决的一些问题。

最后一个code-server，code-server是我们最初看的一个在线开发平台，支持在线去写代码，我们是想和自己的DevOps产品无缝集成，解决开发阶段的环境准备等问题。

code-server很像VScode的在线版，但是我们后面觉得写个脚本还可以，写真正的像JAVA、Python这样语言的时候，还是不太好用，包括代码提示，着色，重构等。 

现在我们还在关注另一个在线开发平台Theia，目前来讲体验上相对比较好，包括像Java代码的支持，后面我们可能更倾向于用Theia作为我们的一个解决方案。

3、提出2021年技术中台的发展想法

作为一个技术中台，其实前面内容描述了我们既有容器云和中间件，也有微服务，流程，服务集成，元数据，数据集成等等，我们下一步想法是这样的：

第一块：我们想把所有的普元产品都放到容器云上来，现在的想法是通过helm来做，形成可完全自动部署的模板，包括我们的运行&集成的平台、效率&精益的平台，都会作为一个个平台组件来做,是第一步要做的事。

第二块要做的事是把我们的效率&工程平台去放大。以前更多的是自动发打包和发布应用与数据，后续我们会考虑支持更多的部署物，比如三方中间件，spark作业等等。

第三块则相对散一点，举一些例子吧：效率&精益平台会去做统一的任务中心，同时补充一些角色的日常关注点，比如像PMO视角的一些报表。运行&集成平台，会将治理门户持续增强，形成跨系统的监控运维。数据交换发布场景，准备按以往实施经验，去做一个相对易用的数据实施工具。

关于作者：顾伟，普元软件产品部主任架构师，先后参与华为，中信银行，工商银行，中航信,阿里云，兴业银行等客户定制项目；参与并负责公司多款内部产品研发工作，长期致力于IT项目管理，总体设计,用户体验及咨询工作。擅长OSGI, eclipse 插件, web 前端，云计算, CI/CD等领域技术,对新技术有着浓厚的兴趣。

关于EAWorld：使能数字转型，共创数智未来，长按二维码关注！