一个传统应用的云原生改造实战

彭小阳

作者简介：朱傲，戴姆勒大中华区 架构师。

一、应用现状

戴姆勒是一家做汽车制造生产的汽车，卖奔驰车，我之前的工作是做应用设计，向企业架构做开源演进设计。我今天的话题是去年将我们的核心系统、客户数据管理的系统传统的应用进行云原生的改造，那跟大家分享我们做实践过程的经验和一些思考。

我相信大家听到对我公司的介绍，应该知道像戴姆勒是一家非常典型的工业制造公司，不像是阿里、腾讯大的互联网公司一样，在它的系统里面往往会存在大量遗留的系统，并且是以很多商业产品为基础构建。那今天谈的系统就是基于IBM的商业产品进行的二次开发。

为什么说它是传统应用，相信大家做DevOps转型都会这个问题，大家都在企业从事技术工作，在企业里面进行信息化的技术发展，已经形成了大量的上百的传统应用。

那目前随着云以及包括Cloub Native成为主流，大家都想把传统应用搬到云上进行改造，在我们公司也是一样，我们现在目前对所有的项目都期望是一个云优先，对所有新项目我们默认采用上云，基于云构建，基于开源软件研发。

但是即使是这样，我们对老旧系统也是需要搬上云，现在已经随着数字化普及程度越来越高，这样的改造已经无可避免，我们必须进到项目里面，进到每一个应用里面，将他们逐步搬上云。

今天分享的项目就是这样，我先简单说一下项目的背景，这个系统是管理企业内部所有的终端用户的客户数据，包括线上线下，这个里面会跟两个区分，一个是IBM，客户的统一认证登陆，这个不在这个范围，另外是CRM，客户关系管理系统也不在这里，这个系统听起来也比较纯粹，就是客户信息数据管理。

这个系统上基本被我们内部所有的系统都引用，都有集成，这个系统是比较核心的系统，特别是现在大家都在关注用户增长的情况下，这里面的用户有一些车主信息都是一些比较高质量的客户信息，所以我们动它的时候非常小心，不能带来数据质量下降和数据错误，因为有可能引发客户投诉。

这里面大家可以看到传统的应用，我在这里面展现了一个架构和传统应用的特点，大家待会听完就会发现传统应用的痛点跟大家非常相似。

简单说一下架构，我们当外部的请求过来，部署在一台VM里面，里面会使用IIB这样的消息队列，然后会对请求进行交验，会使用到IBM的IIS，不是微软的IIS。另外是主数据管理，用到IBM产品，当数据保存到数据库之前会进行排重，同样我们是线上线下客户数据，这是线上部分。

线下是后期构建，所以线上是采用JIRA的技术栈，同时用本地数据库，个人上传的个人资料信息。所以整个一套架构下来大家会清晰我们是单体的，不能没有什么太多的业务的划分、业务的识别在这里面。

在这里面基本上哪怕我们现在每个月的流量在三千万，这个服务的请求数三千万，但是这个数量级肯定跟互联网没法比，但是相对在传统企业里面，当一个企业有每月流量请求有三千万，我觉得已经是不小的数据体量，那这样的系统我们一直用一台VM顶着，顶了三年。

我相信IT系统大家都清楚，我们会要打pad（音），每次这样只能停机等待，等结束之后我们才能真正对外提供服务使用，大家可以想象当我们打pad（音）的时候，我们的客户信息会传到哪？当你给想要买车询价的时候，这些客户信息会存到这个系统，当你登陆官网的时候也需要用到这个客户信息，那么当你停机的时候这些都是不可用的，所以影响挺大的。

同样因为每次部署，因为要停机，我们每次都是晚上干这个事，因为卖车不是跟互联网一样没日没夜工作，系统上面到晚上的时候会有一个使用的低谷，所以我们一般在重新部署的时候都会选择在半夜进行，可能是通性的做法。

那CI/CD不用说了，我们基本上不用想了，我们的代码全部都是上传到商业产品里面去，在商业产品部署，所以对我们来说我们基本没办法做自动化部署，连代码编译我们都没有。

另外谈到扩展，因为商业产品的原因，在中间整个使用费用，基本是按照CPU的核数来算，也就是我们要扩展，要按这个来算。今天发现我们传统系统的改造，软件成本非常巨大，往往是改造的重点，甚至是我们能够改造它的一个动力，一个非常重要的动力，我们能够从软件的license费用省出不少钱完成后面的改造作业。

接下来是商业产品的构建，现在做得挺好的，但是这个生态并没有死掉，活得很好，但是我们还是考虑自身的原因，我们希望把整套东西，首先核心目标是搬上云，这些组件搬上去，工作量会非常大，那我们怎么做这件事？这是我们基本的传统的架构。

大家都在说传统运用的时候，其实往往是带着批评的态度在谈论它，但是如果我们不去思考传统应用给我们带来什么问题以及我们怎么解决为什么要解决，那很有可能会给我带来额外的问题，新的问题会引发。

我们往往谈的时候是说我们的传统应用性能不好，但是事实上大家如果思考就会发现就像刚才的应用，现在目前卡的一个大的点就是它的组织和管理在这个数据的去重、排重性能上很好，如果贸然替掉，这个不是通过我们横向的伸缩就能够解决的性能问题，所以说这个时候我们就要思考，你这个传统应用到底对你来说意味着什么。

所以传统应用其实性能很好，并且在某些程度上面，某些地方是有优势的，如果在这个应用里面认为性能很好，但是它的容量已经顶不住了，待会会讲容量的要求。

另外传统应用很多是基于商业产品，它的健壮性，如果你是快超猛干，比这些微服务的健壮性好很多，因为经过很多迭代打磨，我们经常是一个迭代就上线，你的很多质量保证和日常处理不到位，这个时候健壮性远远赶不上传统的应用。

对我们来说它的健壮性确实很好，那对我们提出了要求，当我们转换成Cloud Native的时候我们是否完成了保证，以及在传统应用里面其实功能非常强大，在专业领域、业务领域里面有常年的积累，有很多业务专家总结出来业务功能，能够帮助我们把问题快速完成，只不过不能满足我们新的功能里面个性化需求不能满足，所以传统应用你要明白能用它什么，不能用它什么。

那这里面我们刚才提到这些多好处，传统应用从商业产品来说还是有很大价值的，这是一个现在对当前的传统应用的价值分析和一些想法，就是我们在做的时候它是达到了一定的要求，但是没满足未来的期望，那我们再做迁移上云的时候，已经完成了，已经做到的事情我们不能退回，有可能是越做越差的，我们要非常小心做这些事情。

二、改造目标

那接下来继续看看，把系统打开剖析一下，看看我们改造的目标是什么。因为今天是我第一次通过线上的方式来跟大家分享我的话题，可能缺少了现场的互动，希望大家在留言区积极留言，后面话题结束之后我们可以一起探讨大家感兴趣的问题，有任何问题欢迎大家随时提问，我如果看到会给大家进行解答。

那继续看改造目标，其实说上云的时候大家首先想到我能伸缩了，这个很重要，挺好的，出了问题就会有Bycut（音），所以大家都是看到了这些好处。但是当你跑去跟业务讲这些事情的时候，很多业务会跟你说我没有钱，产品虽然听起来挺好的，但是我看到了你们做的其他上云的应用也没有做成什么样子，该出问题的时候还是一样出问题，并不是上云就能解决质量不高的问题.

所以大家对于上云这件事情，当在公司里面要去寻求资源支持的时候还是会碰到很多困难，所以大家在业务里面的基本想法和感受就是上云听起来挺好，但是我没有钱，这个钱投资值不值得，不确定。

这个时候就要想想我们这个系统为什么要上云，我们提出的原因是什么。刚才说这个系统是客户管理系统，在现阶段这个系统是在2016年上线的，我这边的数据是2017年，当上线的时候客户数据主要关注线下客户，就是大家通过打电话进来的，通过在经销商店里面留的个人信息过来的，所以我们更多是有大量线下客户数据，是在一百多万。

随着两年的发展，目前我们线下的客户数据大概在三百到四百万，但是还有一个不能忽视的我们有大量的线上客户，这两个是不一样的，大家可以看到架构数据里面我们是有两个数据库隔开的，这里面有一些应用的思考。

但是大家会发现我们线上的客户数据是快速增长的，它的容量要远远大于线下的，并且这个业务在未来我们的策略里面也是线下用户线上化，引流到线上去，能够享受我们的其他的增值型服务，不仅仅是一次性购车之后就完成了，后面的数据化的服务都希望能够跟上，这是未来我们在业务上面的期望。

那在客户数据上的容量层面，我们预估会在未来两年内会增长一倍，这个时候在系统里面的单机系统不错，但是当容量达到一定程度，现在已经碰到的问题，我们再买一个license，再把现在的软件成本翻一番，支撑容量增长。那这个增长一倍，成本增加一倍，大概一年两三百万，数量不少.

所以我们希望把涨的这部分钱用来对系统进行改造，让系统容量能够提升上来，同时能够真正把对以后的拓展不是再靠第二个三百万、第三个三百万license扩展，因为当你数字化程度越来越高，后面的增长幅度是非常惊人的。

所以这是我们的业务目标，当然对我们分析业务目标的时候刚才一直讲，业务里面有一个潜台词，就是我不增加额外的成本，所以我们整个改革过程是在新增的三百万成本缩减下去完成的，我们后面都有这样的约束，基于这些思考我们改造方式方法，都有考虑。

同时里面还有业务上面，做市场推广活动进行车展和市场营销活动的时候，我们选时间的业务访问量，是有七到八倍增长，所以我们要预计短期内有三到十倍的业务高峰能够扛住，所以这是我们希望改造的目标。

那说完这些多，大家可能觉得这么多业务我们到底能不能做到？这个很难判断。那我们做技术上面的时候，在里面自己想要从技术里面得到什么改进，用什么新技术，或者用一个好技术解决这些问题。那在这里面其实是我们公司已经开始，刚才提到的我们是有的云优先的策略，包括我们希望能够拥抱开源.

所以首先第一个目标我们希望拥抱开源能够把商业产品去掉，现在的话对我们后续的业务增长不会被锁住。第二我们去掉商业产品是省钱，再是上云，上云是一个技术手段了，我们希望能够做云原生改造，搬到云上，支撑后面业务容量的增长，包括低成本的容量增长上去。

那我们想要让我们在云上的服务的质量不要比商业产品更差，那DevOps就是不得不要的，在我们环境下就是默认必须做这个事，那REST API和微服务都是我们这次在技术层面看到的技术趋势以及包括我们通过跟业务的结合我们认为需要把API改成REST以及需要以微服务完成这次改造。
这是我们的改造目标，大家会看到这跟Cloud Native里面很相似，来自他们的技术手段，但是我们的目标是Cloud Native是一个技术的集合，我们要非常明确知道这个技术能给我们带来什么价值，我们要和应用这些技术，而不仅仅是我需要做云原生，也不能一鼓脑就把五条放到改造当中去，这个改造成本会非常高，并且你的投入回报能不能得到要求也是一个问题。

所以大家要理解云原生里面的技术真正的核心是能帮你解决什么问题，而不是一上来就要用什么什么，包括我们是不是一定要做微服务改造，因为之前我也做过其他上云的改造，有一些确实做得比较简单，没有做微服务，这里面给大家分享的是运用综合性手段的，所以这是大家在实际落地中需要做考量和考核的，后面也会跟大家分享我是怎么思考的。

三、改造方案

那就来具体看一下改造方案，对业务来说这些改造经历了从十月份到十二月份再到今年的十月份进行第二期改造，业务人员很担心，他们就希望别把系统搞挂了，别出问题。那在制定整个Cloud Native改造的时候我们是按照一二三四五的步骤去分析和思考系统改造的价值。

首先第一个我们要了解系统业务，构建领域模型。了解业务很笼统，可以跟他谈谈业务流程，谈谈用户旅程，包括随便聊天，做个采访了解业务。但是对我们做架构的人来说，当你了解完业务之后，你要构建出来这样的领域模型，帮助整个团队和你对业务的边界范围以及核心价值进行梳理。

大家能看到我的右上角是梳理出来的领域模型，在这里面刚才说的这里面核心的数据是什么？核心的数据是线下用户和线上用户，线下用户有什么比较重要？为什么线下数据体量整个系统里面条目数达到15个亿，为什么两三百万的数据量条目数这么多？

刚才说两三百万的用户是真正有价值的用户，那我们有大量的潜客和访问者的信息在这里面，所以这里面你会发现是整个客户全生命周期的管理，这个时候我们有没有把这样的模型再识别出来，构建出来。这个东西不仅仅是为了技术，也是帮助业务去理解我们这个系统，我们这块业务能做什么样的事情，在做什么样的事情。

后面会发现我们会用领域模型做应用架构，所以大家了解完业务之后一定要有产出，产出就是领域模型，只有把领域模型画出来，才可以说对这个系统有了自己的理解。

接下来我们做系统分析，整个架构需要进行梳理，你的集成关系，有多少系统的集成，用什么技术栈。还有每个技术组件里面承担什么职能，做什么事，你是否心理清楚，待会我会跟大家讲我们的技术组件是怎么看待它的，怎么梳理的，它对我们的价值是什么，未来当我们想要完成扩展之后，以及我们要在约束下面完成扩展的时候我们是怎么做的。

第三步就是性能分析和容量预估，业务的核心目标就是要把容量翻一番，所以这里面我们一定要去计算说我们在机房部署应用以及包括在什么样的计算资源下云的计算资源下能够达到甚至容量翻一番的目标，这个是要记住的，要一点计算出来的，只有这个计算之后你才能知道自己的成本，以及包括你搬上去之后，是不是真的能够做到，你必须要有这样的考虑，包括以后选时的时候，在活动的时候，集中一段时间有三倍到四倍之后，你到时候怎么处理，这都是我们需要做的。

第四个成本分布，这个其实是有点意思，因为我们这里面有一个比较大的约束就是钱，那我们希望马上去买license的费用去覆盖支撑整个系统的改造，所以这里面对成本做了细致分析。

最后是一个识别约束，就是前面我们系统整体的业务、架构、性能做了分析梳理之后我们要知道其实有很多方式方法可以完成，那你选择什么方式方法，你要知道你有哪些约束。

这里面可以看到核心的有三个约束，第一个就是我们有大量的外围系统，这意味着什么？就是我们的系统在去跟外界沟通交互的时候，这是一个客户管理系统，所以它会有非常多的上下游，这些上下游我们要逐步替代，让它做修改，都是小小的对外的调整都会引发上下游的调整，这是我们要时刻牢记，就是我们的改造工作要减少对上下游的影响。

第二个约束就是我们的商业产品，这个商业产品也是一个灰盒，有人问如果是一个闭源产品怎么办？那对于我们下层来说其实就是通过它这个闭源，但是对我们还算比较好的就是它很多上面的二次开发、编码还是我们自己人在上面做，所以这里面怎么做的这些业务大家是很清楚的。

当然我也改造过一些系统是完全闭源，闭源到连数据库都是自己的，是非常小众的数据库。所以大家在里面会有这些约束，我们知道说像这些产品IBM是在支撑使用的，它也会有一些它的上云的方案和规划，所以这些约束大家要去识别和去看。还有反复强调的钱，这个不多说了。

当我们做完一系列评估之后我们给出的方案是什么，其实当大家看业界改造方案上面，总体的思路上面大家可以看到上云的过程可以参考AWS6个R的模式，大概就把我们整个上云改造的总体手段分成六种，每个手段都有适应不同的场景。

这个是我之前先了解的基础，就是我们会用这些手段，但是我们真正不做，我们这里分了三步走，第一是去商业化，第二是服务化上云，第三步是开放API。

这里面第一步去商业化的目的，我们会把很多无用的组件去掉，做了成本分析之后我们发现有些组件不需要，可以省掉，那之后就可以拿Linux的钱做下一步的工作，并且是直接替换人工成本。

我们也会用一些开源组件，外部的服务替换现有的功能，这是在最大化的程度上先节省出来一部分钱，再做这些事，先把我们的钱挣到，再做服务化改造，这个时候就是一个重头戏了，前面做了业务架构的分析，构建领域模型.

其实就对我们的业务，我们需要成什么样的微服务心里清楚，同时我们也对业务理解，我们也知道拆成微服务之后业务会带来什么价值，这个时候我们就可以谈我们为什么要做微服务改造，中间自然我们就会开始做性能提升，其实当大家开始用微服务改造就是用重构，把现在的系统进行最大化改造，这个时候再做性能提升，还是很有空间做这个事。

最后就是开放API，在整个集团内部我们需要这个核心系统做这个事，告诉他集成非常多，那集成的方式是否足够流畅，就会对上下游的依赖包括稳定性也有要求，对上下游的使用方式具有很大的影响，所以第三步要求更高。

那我们接下来具体细看一下这个步骤，第一步我们说去商业化，这里面说做了件事，第一步把IIB去掉，IIS也去掉，MDM重写，DB2也换成了Oracle，这些是结论，那我们为什么能够去掉IIB，目前的架构大家可以发现，IIB承载的目的就是只做了一件事，就是做了接口的转换.
数据传输的转换，相当于这里面不是一个真正的消息队列，并不需要消息队列做这个事，是直接接口访问下面的IIB和IIS这个组件都可以，因为往往是有一步任务要处理有消息队列，但是这个消息队列放在内部的组件集成，并且可以同步操作.

所以大家会发现IIB在这里非常鸡肋，后面评估之后发现直接去掉就可以，唯一要做的就是对外API和对内API的适配。不知道当时设计这个组件的原因，但是在我们看来这个组件没有任何的价值，技术和业务都没有价值。
再看后面的IIS，也说要替换掉，为什么要替换？也是遵循刚才的思路，说这个组件的职能是什么为什么用这个组件？发现这个组件做的就是对请求参数进行交验，当客户输入个人信息的时候进行交验，因为我们需要保持一个高质量才能对后面提供数据保持价值，所以对提供的数据进行了清洗。
本身这个产品有很清晰的纠正，我们就用了三到四个小组件，更多的逻辑还是自己在上面的二次开发，这个就说这里面就有几个功能，地址交验我们集成SaaS服务。你会发现核心看这个技术组件到底有什么价值。

最后一个比较核心的就是MDM，最核心的业务功能就是帮我们做数据查重，那我们能不能替换？其实MDM重写目前还在进行，那它有一个性能，它每天做几百万数据之间的查重和合并的时候，它的性能是不错的。我们觉得还可控的原因是这里面所有的查重排除的逻辑和规则都是由我们自己定义，不是由产品提供，所以说这里面有将近六千多条规则，都是我们一点点放进去的，业务分析人员有六千多条规则注明怎么做，也是用JIRA写的，所以我们有信心重写MDM，核心就是我们后面能不能也实现一套框架或者方法实现查重。当我们具体解决之后，我们就开始做POC了，看看怎么完成这件事情。

最后的DB2，这个是替换成Oracle，主要是DB2贵一些，所以现在暂时换成Orocle，其实我们现在还是想要替换到开源数据库，但目前来说因为我们前面其实是要一步一步调整，所以步子还是迈小一点，暂时替换成Oracle，后续还会再调整。

这个就是去商业化，这里面非常大的核心就是大家要去想，我们在碰到这三样产品的时候，你要核心掌握的是最大的难点就是你对这个商业产品上面构建出来的系统业务支持是否足够，只要足够，后面可以通过很多不同的手段去完成对它的改造，如果缺乏这样的业务知识，这才是真正最大的问题。

刚才说的闭源系统就是存在这个问题，业务知识都是缺失的，后来我们都是先学了业务知识的，所以工作量很大。当然也有不适合的，我们是一个卖车的系统，对于HR的系统可能就不需要学习那个知识，没有那么大的价值，但是对我们来说必须掌握核心业务系统，如果自己没有掌握，其他的厂商会复制。

这是我们在商业化的时候我们的案例，我也相信每个场景有千差万别，有的会更困难，有的简单。

但是核心第一要有业务知识，第二要知道核心的价值是什么，你用核心价值是否能够用其他的方式解决和替换，次重要的其实可以不需要，这里面我们也抛弃了很多其他的组件，都没有画出来，就是卖这套东西的时候带来很多组件，我们直接抛弃了。

这是刚才说的商业组件，接下来就是服务化上云。那服务化大家看到我前面做的领域模型，领域模型这个时候就转换成微服务的设计，这里面我分享一个我们做这个业务微服务的原因是他们在做他们的投资组合管理，管他们的钱怎么花之后，通过微服务就知道他们钱花在哪里。

以前不管是做线下线上融合，业务的综合，数据的清洗，大家都是笼统说我要修改我的客户数据质量，就是这样的话，每年几百万钱扔进去，但是如果把服务分开，我做的其实就是，比如说会员体系，就把会员体系调整好了.
我们有车主俱乐部，有车迷俱乐部这些整合起来，我们今年做的就是把线下的用户数据搬到线上，做线下线上融合，这些大家发现投在不同的业务里面你的投资组合就非常清晰了，这是我们做的一个工作。

后面开放API，这个是非常明确的，我们看准了这个方向之后，我们认为需要往API化方向走，我们提的要求就是在所有的服务当改造的过程都要暴露出API，API是在设计、监控以及整个的Developer都有要求，并且还有成熟度模型，包括团队把这些做起来。

四、云生态改造总结

最后我做点总结，这里面其实我还没有给大家讲的就是CI/CD，因为时间有点长了，我快速讲一下，我们稍微回顾一下刚才说的这个方案。

大家发现前面第一个就是要理解业务，识别技术组件的价值，每个技术组件对你来说意味着什么，就在这个改造的过程中，当我说要把IIB干掉之后，另外的架构人员团队开始给出云上的架构，因为我要说做微服务，上来先把这个挂上来了，我就问它这个对我们意味着什么，他说注销发现（音），你的微服务不需要注销发现吗？

我说我不需要，他就愣了，说为什么不需要？因为在我们整个环境下，我们所有通过API网关的方式做，每一个微服务都是独立发布自己的API出去，大家通过API集成，我们把每一个微服务当成独立的业务，所以不需要中心化的组件来去控制它。

我们服务的治理其实是一个比较落后的方式在完成的，我们没有那么动态需要实时新的服务器加起来，每个加起来的周期比较长，不会在分钟级，这个时候不需要这样的路径。所以大家要知道你每个技术组件是干什么的，这个是要想清楚，能不能带来价值，这是要提醒大家的。

第二采用6R的方式，我们不仅仅改到Rehost，我们要做深入的探索，看看综合应用六种替换的手法。

云原生改造的时候技术非常多，包括最基本的12因子，大家上云的时候还是要坚持一下12因子，除此之外我们作为技术人员还是要考虑一下上云要做云原生的时候，其他的改造是否跟上了，容器化肯定会做，但是不是简单搬上去，其他的还会受影响，会发布不出来。

最后一个就是前面没有跟大家分享的团队工程实践能力的培养，这个前面一直提到的就是你搬上云的时候会不会退步，懂不懂怎么小步把能力验证上线，大家也可以看到我们第二步才做微服务改造，第一步是把组件去掉，第一是钱的原因，第二我们要看接口测试是否需要补上，有没有这个能力去把这些工具应用起来，使用起来，这都是我们在前面第一个阶段的时候开始做的事情。

所以这个是一个整个完整的我们希望能够搬上云，但是不要享受到云的好处，因为改造把质量又拉低下来。