本文内容由CIO发展中心根据某集团轻咨询服务案例整理

2022年已至，新年伊始，CIO发展中心继推出“智慧选”服务后，特别推出“甲方专家轻咨询服务”，邀请分布于几大核心行业，跨越数十种产品领域、从事信息化、数字化10年以上的百位业内专家，组成强大的专家团，输出针对选型、实施过程中的轻咨询服务。

我们希望这项服务能够针对企业在选型调研和实施过程中的典型问题，帮助企业对接同行业或者相关领域的甲方专家，通过甲方专家自身的实践经验和Know-how, 对有关业务需求进行评估、对应用趋势、产品特点、差异化、适用性等问题进行解答并给出合理建议，以此来帮助企业实现更加高效的数字化转型。

近期，群里有位CDO联系到CIO发展中心，希望能联系云原生方面的专家，从第三方的角度给出一些建议。通过和CDO仔细确认需求，我们邀请了知名专家和集团CDO进行1:1视频沟通。以下内容为整理的部分观点，内容略有删减。

咨询需求：目前集团采用的IT架构是Java单体系统，能满足目前企业的业务需求，但是在业务互联网化的要求下，仍需要搭建一个互联网信息交互平台。此外老系统没有按照服务化的思路构建，存在重复建设，系统版本老旧等痛点。现在面临云原生选型，想和专家咨询关于云原生数据中台、云开发、Serverless容器云等相关问题。

问题1：现阶段的首要任务是构建新系统，迭代老系统，全面提升技术能力。在做系统架构设计的时候，应该如何把握？

专家：对于大多数企业的来说，目前都在广泛讨论两个方面的话题，第一个就是类似于服务中台，以云原生为核心的应用如何搭建，并且如何来支撑互联网化的应用；第二个就是数据中台，如何充分挖掘数据的价值。

从大原则上来说，云原生的应用架构有三个核心能力组成，分别是微服务、容器、DevOps。企业首先需要结合业务的实际情况，来进行微服务的建设，微服务建设要以领域模型为核心，围绕业务来进行业务逻辑的拆分，核心理念为高内聚、松耦合，但是想要做好并不容易，需要考虑到边界的问题，通过业务的功能来进行划分是解决的方法之一。完成模块拆分后，每个模块相当于一个独立的个体，后期以便快速迭代，不断优化各种能力。 

问题2：在集团的各类系统中，超过50%为外包系统，如何通过云原生工具，将所有的外包系统管理起来？新系统与老业务息息相关，新的应用系统架构要去逐步拆解单体系统，将不同模块剥离，形成独立的服务，这应当如何操作？

专家：很多企业早期建设的应用都是单体的应用，现在不得不转型到以云架构为核心的应用开发模式上，如果是构建新的研发能力，一定会基于微服务、云原生来进行建设。目前来看，老应用在新模式中的迭代，并没有很好的办法，从架构的角度来看，只能是“拆”，也就是采用扼杀模式，首先将一些通用的，与新业务模块交互多的服务逐渐进行替换，下线老旧的能力模块。当然这是一个具体落地的问题，难点在于对不同模块之间耦合度的把控。相比较，单体系统耦合度很强，如果力度太粗，可能达不到想要的效果，如果力度太细，可能工作量太多，而且达不到拆分的要求，因此在落地时，应当对老应用进行一个全面的分析。

另外一个值得思考的问题是，能否借助云的能力，让传统应用在架构上更具弹性。我个人看来，很多传统应用的问题集中在非功能性层面，少量用户还能够支撑，用户数量多了以后，压力就会很大。因此将以前的部署模式平移到云上，利用云原生的能力来增加弹性可能是一个机会点。

在新老应用的交互上，首先需要判断老应用是否具备外部服务的能力，如果没有，需要借助一些中间件来操作；如果有的话，则可以基于接口进行对接，避免直接调用数据库，这是基本的原则。 

问题3：在应用搭建初期，是否需要建设API网关？

专家：这里可能会涉及到协作的问题，设计API网关的必要性在于应用架构的移动端和服务端是分离的，需要一个统一入口。对于前端的应用开发者来说，更希望有一个统一的入口，因为前端服务变化的力度要远大于后端服务的力度，所以开发人员更愿意把精力花在提升用户体验的一些功能上。个人建议一定要先行建设API网关。

不只是API网关，有些架构需要一开始就建立起来，因为现在的协作模式不同，以前是一个web应用将前端全做了，现在完全是分离的模式，两个团队的协作如何做集成是需要考虑的。从工具角度来看，API网关是一个能够完成屏蔽后端复杂性，传递给前端的过程。 

问题4：目前企业内的容器选择的是阿里的产品，那么应该如何选择合适的DevOps工具？采用了阿里的容器后，是否还可以架设其他厂商的DevOps工具？

专家：关于容器，我认为现在各大云厂商做的都还不错。首要原则是一定要选择托管式的产品，企业一定不希望在搭建和运维基础建设上花费大量的精力。其中有一个需要考虑的问题就是要选择与容器相关的DevOps，它们是一体的。微服务与业务逻辑相关，与底层系统并没有深度的绑定关系，但是一定要考虑到容器与DevOps集成是否足够简单、开箱即用。

在厂商的选择上，我建议不要在一个应用里面使用跨多个厂商的工具。首先它们之间的集成很难，会耽误进度；另外它们有不同的数据中心，网络及其复杂。所以最好还是基于一个应用，选择一个云厂商来提供它的服务能力。 

问题5：在我们提供的企业服务业务中，销售管理上成交来自于多个平台，会涉及到交互管理，要求打造统一的企业核心信息库，并且要抓取企业里各种各样的数据，存储到数据库中，并且团队中数据板块人员较少，这种情况下，我希望数据中台能够帮助建立这些核心信息库，同时也能够拥有一些基础的分析能力，并且能够与微服务的接口进行集成，这应该怎样实现？

专家：数据中台的建设比开发系统建设的复杂性要多一些，一般的数据中台是以处理非结构化数据为核心，从以上提出的三大需求来看，传统的BI能力更能满足，ETL工具能够支撑数据的抓取，接着就要确定主数据的模型，通过ETL将数据获取到数仓，进行数据分析。数仓是真正进行数据分析的核心组件，在推进的过程中，数仓的云化是可以与厂商来探讨，选择需要的组件分阶段推进。

基于您所在企业的人员结构，还需要考虑复杂性的问题，提升人员的能力，目前不妨还是通过DataWorks来解决前端的开发瓶颈。客观来说，人员能力的提升能够解决系统锁定的问题，成本控制上可以先使用最小配置进行试用，后期逐渐扩展。 

问题6：目前企业正在选型低代码产品，用来解决集成的问题，希望能够进行快速验证，并且数据流能够与现有系统打通，您有何推荐？

专家：低代码平台有两种模式，一种是以流程驱动，本质上是一个工作流，用户可以自定义表单，而表单就是业务的核心组成，这样的模式自成体系，是独立的自应用。另外一种就是数据驱动，接入API或者是数据源，反推出UI。针对您所提需求，我认为第二种更为合适。 以上内容就是小编根据专家的答疑整理出的问答精要，希望能够对大家带来帮助，大家如有甲方专家轻咨询需求，欢迎点击二维码进行填写，我们会尽快与您取得联系。