2020年12月第2届中台战略大会-云原生技术应用现状总结

关键词:

抽象、微服务、复用、架构、社区、企业级、应用层、多语言、体系、业务模式、最佳实践、咨询公司、退出机制、技术问题、战略大会、系统结构、技术发展、技术视角

文字记录:

带佬 05:18 

大致是这么一个背景，就关于这个会好，我们今天会分享这五块内容，一块是那个小鹏汽车的那这块确实是和我们当时其实在群里面给大家发了说这个东西有一些内容推荐给大家，这块确实和我们目前做的相关的一些内容，就是关联性比较大，就是是还是蛮接近的，很多东西这是一块。然后第二块的话是中兴银行的其实我在我们小群里面发了就说这个它里面其实怎么讲，就是银行产业在这个里面，在云原生里面。是怎么讲？就是还是有不少人在做不少事情，因为除了他以外，之前在社区收集的一些还经常能看到，比方说兴业什么在做一些相关的事情，但是银行的历史包袱是非常非常重的。所以我们换一个视角看一下这个不同的场景，他们做原因是做这个中台是怎么一个思考。然后他讲了这个这位嘉宾讲得挺好，包括里面一些思考，我觉得还是值得我们学习的。讲出些东西来，确实讲出了一些东西来。

带佬 06:30 

一位处长然后再分享一个比较神棍一点的，这个是 Salesforce 的 sale works 的话，这个因为熟的同学大家都知道对吧？ MA Martin follower follower 同学的公司，神棍各种现在大家耳熟能详的这种微服务，包括这个 collect tecture 这 domain domain 这个迪，我记得好像都是他造出来的。这个整个公司基本上为大家读这些云生的书，就是包括我们买的一些很多都是他们出的。

带佬 07:04 

我觉得 market forward follower 同学， follower 同学我觉得已经属于神棍级的这种专家啦，就是造了很多名词，然后她们的这个整个公司给我的感觉就是可能这个面试可能就是先来做一次是这个presentation ，然后展现一下自己就非常需要，后面会讲到这个演讲的能力都非常的了得到。然后再给大家讲一个这个我们的第一大这个这个这次活动第一大赞助商，这个网易，网易数番他们那个一个架构的介绍。然后最后的就是有一个感觉，因为这里面中台包括业务中台，包括数据中台。然后讲数据中台的人其实很多至少有一半是讲数据中台的。然后我个人觉得在数据中他我我个人不是很熟，但是在这里面我觉得这位就是袋鼠云的是讲得比较好的，那他们其实也是从阿里这边脱离出来自己做的然后我觉得他是属于讲得比较好的，能够讲出一些东西的其他人可能反正一方面没他讲得好，一方面就是这个从我们外人的角度来讲，可能看出来就是可能他讲内容更易理解一点，更讲述一点干货前两个其实像小鹏和这个其实中心也是干货比较多一点。好那我们就很快开始。

带佬 08:26 

这小鹏之前也在群里面给大家分享过，然后辉小辉同学这个线下和他灭了个鸡，所以和他了解了一下他们的情况，他们是这样的，他们当时是在几年，小普他们这些系统做的是在我记得后面讲的是在 18 年左右做的，然后他们这帮人是就小鹏主要在广州，他们他也是在广州飞过去的，然后他们当时相当于说是某某云，他这里没写应该是他们在哪里之后自己搞了一个啥云后来挂了。然后所以他们那个团队几个核心成员，然后就一起投奔这个小鹏了。他据说据他说是先他们有个架构师过去，然后他们就拉着他们一起过去。所以说他们相对来说就是有这么三四个人，四五个人相对来说原来就是比较熟悉的就是一伙人。然后过去小鹏之后，然后用了差不多一年不到的时间，然后把整个这个类似于我们的云原生的中台这么构建起来的。然后他他这次的演讲其实一个是 30 分钟，他超时了超了将近 10 分钟的时间，当然里面夹杂了 5 分钟的放小鹏汽车的视频的时间。然后就讲他那个过程里面他们做了些什么事，18年到 19 年做了一些什么事。然后的话对于未来一些展望，属于说在这些今天的那次演讲里面比较干货比较多的一个演讲啊。

带佬 09:59 

啊倒也不不单单是说这个是我们社区的一位这个好朋友这个，然后推荐一下这个，而且他确实是他也说了参与了小鹏汽车技术中台，他借这个技术中台偏向于就是云原生的技术中台从 0 到 1 的设计开发与演进。所以其实很多和我们那个他这领域和我们有点像，还是值得很多我们去回味一下或者说去学习一下的地方。

带佬 10:30 

这个小鹏是这样，他是 15 年成立的对吧。然后他们这边开始做，基本上是从 18 年开始做的然后他相当于说他加入的时候，当时是迅速扩张期，然后的话是有 19 个微服务，有一个 data 3 层当时背景是这样的。然后他差不多是四月份他们开始过去做这个事。然后他们的问题是他们其实也是他完整地讲了一下他当时 0 到 1 的这么个过程，这个其实是挺好的。然后看开头的问题就是缺乏基建，测试效率不高，出现问题也缺乏出现问题定位的手段有限，缺乏统一的技术规范。

带佬 11:09 

他们的技术栈是 spring boot 他们当时最早是 spring boot 但是也会虽然说是统一的一个技术栈，但是也会受限于这个不同的版本，这个和我们当时都是做Python ，然后 Python 当时其实还都没升版本的，包括现在其实升了版本，大家知道这个 Python 升个版本的代价是非常非常高，当时其实也从 2 升到 3 了，就是 highlight 这个，且版本迁移比 respring 那个我觉得迁移的这个成本更高。

带佬 11:39 

其实当时也是有这样的问题，然后可用性也是有问题，就缺乏弹性，然后挂了就是挂了没有什么支撑手段。其实会发现其实当时的一些问题其实都是非常类似的，包括后面讲到网易，你说从一个大厂的视角其实也都是这些类似的问题，非常很常见的这样的问题。就当时他们就做了怎么去呢？然后就首先要做第一件事儿微服务化，这是比较容易想到的。然后他们就利用了 spring cloud 把 springput 那些原始的资产，然后把它微服务化，然后进而容器化服务编排走 K8S 再加上走自己的一套 devo 系统。然后他们自己内部做了一套系统叫 logan log in 的话大家知道这个一看图标大家就知道是什么我们的金刚狼这个我不知道为什么起这个名字可能也是 X man ，和这个有关系，小鹏这个是 X 对吧，然后他们会包含这些体系，巴拉。

带佬 12:38 

所以看到这里其实就会发现这个东西是不是和我们当时的发展历程就很像，当时我们其实也是这么一个过程，我们做了微服务化虽然当时其实我们先是从边缘的服务微服务的，其实到现在我们还影子服务做完，我们还有一个 Backend 的这个一个服务里面 N 个进程的问题还没处理掉然后加上 K 引入 K8S 加上建立云朗的自己的 Jenkins 的 DevOps 体系加上到后面我们开始接入什么，接入 Google sphere 一个我们的云的一个开发云的一个管理平台。

带佬 13:19 

其实你看我们不同的其实是各自做的。其实如果你去看这个演讲里面其他一些嘉宾分享，其实也会发现说这个路线其实非常非常类似的，包括后面讲到那个网易云为什么去讲网易就是给大家看一下，即使你可能觉得小鹏也是个小厂，那你看看大厂是怎么做的，其实都是非常非常类似的思路和路径。

带佬 13:44 

好，接下来就是那有了这些的话，就是要有了一个基础的基建，那要做什么事呢？就是要赋能业务，那毕竟是一个技术中台，技术中台的话要解决的更多的问题。或者说除了就是把云学生这个技术引进来之外的话，技术最终还是为了服务于业务的所以的话那下一步可能要赋能业务。那当然复制业务的角度其实还是通过一些云原生的一些技术去做的。包括说就是使用一些微服务的最佳实践包括说通过引入什么，你看日志中心、注册中心全方位的监控。其实他们那个时候相对来说可能做得还比较早。其实那个时候他提的这些其实也就是我们说的这个可观察性的一些事，这肯定是要做的。

带佬 14:34 

因为你微服务化之后，你不做这些事，其实就是真的是叫假微服务化。因为你没有去领会或者说没有去实践微服务的一些核心，或者说微服务或引入那些问题，然后你都没有真的去面对那些问题，完全是假微服。然后无缝落地，包括是数据埋点，包括一些代码生成企业这些这块其实也会在后面会提到，它其实这里已经有一些这个 low code 的一些概念。然后自动化、网关接入服务自动化平台接入、自动化 CICD 这些也是逐步去夯实的过程。

带佬 15:11 

但是这里要强调一下，就说这些事，你看他们是一个专门的，他们这个团队是一个专门的技术中台的团队，或者说理解为是专门的一个云原生中台的团队，她们就是专门去有精力去做这个事的。然后看到这一页，其实就会想说这些事我们有没有去做？或者说我们为什么好像这个这个边做边在，就是修修补补，缝缝补补这个去做这些事了，或者说不是集中去做这个事了，因为我们团队的这个现在的架构组织还不太一样虽然说一直希望可能我们发展到之后人员相对充足，或者说业务增长之后，这个随着业务的发展，我们需要更能够有引入更多人之后，我们有一个专门的原生的中台，但是目前其实没有这样的团队的，我们更多的其实是静静这边和我们这个我这边像那个可慧兄，就是我们是随着业务的开发，然后抽出些时间去填补一些当时技术中台上的或者说云云生中台上的一些空白，更多是这样做的，他们基本上是全力去做这个事情，你能看到他们一年左右就把这个事情做出来，原型做出来，然后再花了一年去迭代，把它夯实的好。

带佬 16:24 

那接下来他就是他前面讲了一下他们大概做的一些workscope ，然后他这个是一个，然后他这个是一个时间线是怎么样？就是 18 年 4 月份启动的做了一个中台属性之后，8月份接入第一个府，然后正式上线是 12 月就年底相当于说做了 8 个月，然后把这个中台正式上线。然后 19 年开始支持大规模的项目落地。然后夯实中台，然后到 20 年今年去年的话主要是平台的稳定词，然后夯实功能，然后的话查漏补缺所以你空他的这个时间轴，你也可以看到说他们是一个定位在比较完全是一个技术中台的一个团队去做这个事情。其实我觉得可能和当时小鹏就是刚属于那个技术人员那个大的扩张有关，他可能也愿意就说抽出这些人去专门把这个事情组一个团队的形式组织起来去做。

带佬 17:20 

我们目前可能还没有到这个境界，以及说这个大家也知道这个这个对，要推动这个事情也不是那么简单的对吧，这个反复会有很多声音在这个里面，特别是有当你历史包袱越重或者说我们其实历史包袱还好，但是说包袱不单单是会技术上的包袱，又一些思维上的一些包袱。所以在企业文化里面，我们这次也特别强调了 embracing X 也是我这边主导去提的这个去去优化的一些点，希望大家在这里能够多输出一些案例。好，他们的这个眼镜多维度眼镜这个他们主要是一是可用性的保障，这块其实会比较像，第二块是那个支持多语言和 GPU 多语言。

带佬 18:07 

其实我们从一开始其实逐步从就有 Python node 包括发展的 go 其实一直有，但他们这边因为他们真的是做基础中台，所以不像我们就说我们更我们现在说我们是业务团队，然后包括我们业务开发加上运维测试团队，我们抽了些时间去做中台的事儿，我们可能就只专注我们现在这个我们业务上用到哪些事，所以他们是专门做这个的，所以你看他还要管 GPU 的事，当然他们 GPU 也会用到一些的，所以他后面还会提到一些 AI 的事，会有一些 GPU 的事我们这些就没有管了，因为我们目前还没用到对吧。但是其换个角度，其实如果你把云脑拉大一点来看的话，像数据这块其实也应该在云脑子里面的话，其实也应该在这里面一部分工作。只不过我们现在还没有，我们我们现在做的这块事还没有涉及，然后应用层的抽象这块其实也比较容易理解。

带佬 19:03 

包括说最近其实一直也在关注的就是 OAM 因为 OAM 的话最近其实出了一个比较可用的怎么讲一个项目。因为之前其实还是停留在概念上比较多，然后很多东西还是要通过模板化的这个东西去做。现在它出了一个比较可用的项目 copy zilla 所以这块也比较在关注它更多的是应用层的抽象，包括从 service mesh 的角度来讲，有那个 dapper 这个也是另外一层的一个 sidecar 应用级的业务级的一个 sidecar 的抽象。当然这 list 有更多的是一个基建级的一个 sidecar 抽象， example 的是更多偏向应用级的 sidecar 的抽象，那应用级的应用级和业务级的更多于偏向。比方说我有一些基建能够帮助你访问一些数据库，帮你访问一些特定的一些存储这些应用级的抽象她们也在做这方面的工作。那另外就是提升效率和资源利用率。这个毫无疑问是每个做中台和技术和机械必须要和设计的一些工作。然后在可控性的保障这块的话，目标 4 个9。然后那要做这些事情，你看业务无损升级，然后服务治理，异地双活，自动扩容反氢和氢混沌工程我们不目前除了这块没做，其他其实都有在涉及。你看这所以做的事情其实殊途同归真的其实你真的深入去做了。那之后的话你会发现其实大家的你只要真正是想去做好这件事情，然后的话你就结合现在的这技术发展的话，你会发现其实大家的思路和这个做法很多时候是比较相似的，特别有在云文生目前这个环境里面，就说大家的这个受到了知识其实他的这个领域比较广，然后也能刺激大家很多思考。然后抽象总结之后的话，其实还是能够比较做好聚焦的无损升级、滚动升值策略，然后解决状态不一致的问题。

带佬 21:02 

然后 timecase 又好退出这块他们还是用 timecase anyway 就说这块。其实我们现在做得还比较少，最近也有不少文章主要在讲说怎么利用 K8S 它的这个一些退出机制。这块我们在 k8S 的 patterns 没有讲过，包括一些这个 pre stop，包括一些这个一些其他相关的 hook 的退出机制来保证容器优雅退出。

带佬 21:26 

那优雅退出的除了保证就是说其实直接挂有问题不大，它更多的是能够保证在容器退出的最后时段能够把一些错误信息能够收集下来。就类似于我们现在虚拟值挂了，阿里云虚拟值挂了，然后要收集 call down 这个好复杂对吧。然后的话它其实有类似的问题，那我挂你就挂，反正我可以重启，但是你挂的时候你把你的最后的材料这些信息状态帮我收取回来。那这个时候我要争取一些时间。

带佬 21:55 

那怎么做呢？很多时候就会通过一些这个 UI 推出的一些机制去做支持多语言，这边就不讲了这个。反正那他这里主要讲一下为什么要支持多语言，他这个语言就是多语言和 GPU 他这边主要是因为他们有那个车上有这个小 P 的智能助手类似于 Siri 的智能助手啊。啊他当时放了一段那个视频，然后还是感觉还蛮好用的。然后他们那这套体系其实就是比较标准的基于 cookie flow 啦其实就类似于 cookie flow 所以它当时做的还不是 cookie flow ，它当时还是自己 cookie sphere k8S 上面自己搭了 tensorflow Python 的东西去做。

带佬 22:37 

现在基本上主流的做法其实都是走的 goodfloor 包括之前蔚来也分享过他们基于 copy flow 做了一些实践这个其实我们很早之前其实都有 touch 过类似的东西，在研究云生的那段时间，特别是功能这块做了挺多的一些预研的工作。但是比较可惜，可能我不知道现在有没有利用起来，而且当时回过头来说比较可惜的更多的是说当时其实花了很多时间去调研这些事，然后用来说服大家这个东西我们还是有用的或者怎么样。

带佬 23:14 

其实那些时间回过头来想，如果那些时间我们能充分利用起来的话，我们其实也能把我们现在的中台做得更好，那这是题外话了，我们就不展开了。 OK 接下来他提到说当时也会，为了业务的赋能，业务，他会把一些东西抽象出来，沉淀下来，把它真正沉淀成为一些中台的能力。

带佬 23:32 

那怎么去做呢？那比较容易想到的就是通过 sidecar 去做你可以看到就说 18 年他们很多东西是 18 年做的，18年这个时间其实我们很多东西也是 18 年做的 18 年那个时候，坦白讲是之前也给大家分享过是 k84 真正爆发的那一年。但是爆发的那一年也意味着说当时其实还是很多新的，现在从我们现在的角度来想都想通想的东西。

带佬 24:00 

比方说你要 sidecar 那很简单，你要做基建list ，你要做一些业务的沉淀，中间复用中台能力或者说业务的沉淀。那你首先先看一下 dapper 对吧，你这个能不能有能用的话我们再看一下，不能做的话我们就用 sidecar 去做。当时你看他现在还提了 suspash 的雏形，当时 18 年很多这些东西其实都是属于还是比较混沌，还不是那么明确的一些年代，就做得早有做得早的好处，做也有做得晚的好处。所以当时他们相当于说就自己做了一个这个事情。

带佬 24:33 

然后其实做的方法和现在回过头来看，其实就是现在主流的一些方法没什么太大的变化。好应用层那这块它主要强调是在当年还是那句话，在当年他们做了个什么事呢？就是因为应用部署了，我们这个应用的能力和运维这块其实还是有很多 overlap 的地方。但是为了更好地去做运维，他们自己发明了个东西叫做 bo ot 它等于我们的 deployment 加 service 加 hva 加 resource 加 PVC 加 parity 然后它们把它冲向成一个特性和工作负载工作负载，比方就 deployment restful ，然后它把一些其他相关的一些属性抽象为一个特性，然后组织成一个应用。

带佬 25:18 

然后讲到这里，其实大家应该清楚，他当时就做早了。因为其实如果大家熟悉我前面讲了这个 oam 就是微软和阿里推出来开放应用模型包括我前面提到的现在这个相对来说它一个实际里的这个应用酷不酷 leader 其实就是这个事，它的概念就是我们现在做运用部署和运维其实还是比较吃力的。它最大的问题就在于说你的应用的一个载体，你的 workload 比方说你的这个 deployment 或你的 stayful set 和你的一些它是一个属于主体。然后你有你会有非常多的一些负载的负载，它身上的东西比方说服务，因为你你的你不一定要有一个 workload 一定要有服务的对吧。比方说你的一些这个你的资源，比方说你的这个你要做不做那个 hpa 包括说你挂载的存储这些东西其实和你的 workload 应该是一个需连接的，是一个松耦合的关系。那如何让它能够更好地形成一些松耦合，让它能够即插即用地做一个绑定呢？你当然可以我们通过我们的 operator 去做类似的事情了。然后也有很多人类似小鹏在 18 年就做了这个事。然后 oam 这个体系其实就是为了解决这个，然后他就很明确地把它分为我 close 和 trace 特性，它把它翻译成trace 。然后它提供一些工具它当时其实 OM 没提供工具，它提供的是一些声明的方式。那你可以把这些东西能够快速方便的整合起来，让它使得说真正在 DevOps 的环境下，是一个开发者都能做这些耦合的一些过程。

带佬 26:59 

那像我们其实大家知道，现在我们只是要求我们的开发者，我们的研发人员能够做到自己把 Docker 镜像做出来，那后续怎么部署？这是真正生成上面这一块其实是要我们的运维同学比方说主要是许娟对吧，那在做这部分的工作。那这个其实从 DevOps 的角度来讲的话，其实还是没有真正演进到一个真正的很充分的 DevOps 但是如果有了这套体系的话，能够把这个过程能够变得非常的简化和易用的话，还是一方面是能够提高大家的这个运运维和平时的工作效率，一方面其实也是能让你整个这个东西上升一个台阶的，这里就不展开了。

带佬 27:39 

然后它的 device 体系其实也可以看到很多时候。其实也是CICD ，当然我们现在 CI 做得更多，CD做得比较少，静静也在昨天的这个我们的对齐会上也讲了，后期我们把 CD 这块做更改好一点，他们其实也是当时完全花这个力量去做这个事情。其实可以看到就是说我反复在说就是说其实你可以看到这样一个团队，让他们 focus 地去做这个事情，其实很快能可以做不少产出。当然我问了一下他们团队的组成，就是说还是很多 C 列的人，而且说他们是在一起摸爬滚打了很长时间，这个确实是有他的这个非常好的一个优势。但是我还是想强调是说很多东西是要 focus 去做，能 focus 去做的话，它的产出我觉得一定是不一样的。

带佬 28:26 

O OK 他们然后也做了容器化的部署平台，其实就类似于一个专门专用的一个 CD 的一个平台。这块我倒是觉得说怎么讲包括他这个 logan 的一些东西。从我现在角度我讲，我觉得是说我们不算晚。然后的话我们更可以利用像现在的 coupe sphere 它本来这么一个很好的 3.0 出来出来之后，一个很好的一个开放性的平台，包括如果大家有关注他的 cobsphere 的这个在去年年底的这个技术 meta 大会上，他的分享说 4.0 会到一个新的更高的互相能够更加开放的一个平台，能够有更多的开发者能够来融入进来做自己的定制。

带佬 29:11 

那期望到这一天之后的话，我们更可以把我们的很多业务的东西能够融入在这里面，然后同时基于它的基础能力，包括多集群管理，他的 federation 的能力，包括他的一些 CICD 的能力去把我们的类似的平台能够做出。所以我觉得这倒不是说我们可能是一个后手，但是不一定我们没有后手的优势。我觉得还是我们只要用好一些和社区里面比较好的一些产品，我觉得还是很有希望把这块做好的。然后它这 CICD 我就不展开了。其实可以看到其实很像很我们要做事情很像，而且一般来讲包括大家能看到其实还是很多是和那个 Jenkins 相关对吧。

带佬 29:49 

Jenkins 到目前为止，虽然说现在在云原生的这个 CICD 领域里面有非常多的一些竞品和 jkins 挑战 Jenkins 包括 jkins 自己也在革自己的命对吧？有 Jenkins X 但是不容置疑的是 Jenkins 还是凭着它的插件的积累和那么多的底蕴。它目前还是各大厂商各大云商用得最多的一个， CICD 的平台环境这块我觉得还是毋庸置疑的，所以我们还是可以基于这个去做好。而且还是那句话就说包括 copy sphere 我们可以充分利用。

带佬 30:22 

好，copy sphere 它里面用的植入的还是 jcins 而且 copy sphere 它的它们这个社区里面，它现在里面有不少 jcst member 参与在这里面做这个相关的 CICD 的工作开发，我觉得这个还是有机会把这个事情能够一起推动起来去做好的。至少我们可以去参与一下，然后去多尝试一下看看。包括，你看他们小鹏他们也是 hover 对吧。

带佬 30:47 

song cube 你看 nexus 这个类似于我们内部存储的我们用的那个reduce。有差不多的，他基本上套路真的是差不多。 OK 最后 GPU 演进我们就不讲了。然后最后他就提了一下云原生的思考。现在从 18 年 12 月份的这个数字，到 20 年 12 月份，这个肉眼可见的翻了一倍，整个数字基本上都是翻了一倍。这个是两年能达到这个程度，包括它这个曲线这个是一个相当不容易的成就，包括不说社区的参与度。

带佬 31:21 

其实可以看到说云原生这个东西从现在来讲的话，未来如果你要去做云相关的一些工作，你离不开云原生如果你不了解云原生，那你这个就可能在后面的工作开展上就会处于劣势。 OK 那最后他又提了一个服务网格，现在他们那个问题现在他也在积极地参与微软提出了这个 open service mesh 这块的这个工作，因为这块的话他们因为做 spring boot spring cloud 相对比较多，然后他们也在继续参与社区，也秀了一下肌肉，其他后面就不讲了，因为这个这讲了挺长时间了。 OK 所以第一块就是小鹏。所以总结一下就是小鹏这块基本上整个过程和我们当时 18 年的 18 年的这个时间点是很像的，当时的问题也是很像的。

带佬 32:15 

然后但是其实就是两条路，我为什么把它拿出来要专门讲，花了这么多时间专门讲，因为我的感慨非常多，我觉得就是时间点都差不多，然后可能人为投入，如果你当时我们要夯出这些人，可能当时倒薅不出的事，说真的是投入不同。然后的话认识不同，专注度不同，而不是认识不同，专注度不同。然后你能看到说现在我们的程度可能只能赶上他们 19 年的这个程度，可能就差了一年的这么一个时间。倒不是说我们做不到这个程度，我相信我们未来可以 catch up 少。但是我觉得一个事情的认定一个事情，然后 forbox 去做，努力把它做好持之以恒地把它做好。我觉得能够产生的能量大家可以通过小鹏来看一下。然后我觉得小鹏也是激励着我们说以后我们能在云原生这边也能够去做到这样的程度，甚至说做得比他好，我觉得是完全有可能。所以说大家也在这块的话，大家我们可以继续努力一直去做。

带佬 33:24 

好，那这是第一个是小鹏，第二个是这个中兴，中兴这个就比较有趣一点。因为银行这个其实我为什么拿这个来讲也是因为我听了这个其实也觉得感觉其实银行他确实有想法的也是有想法。我听的时候我就发了个消息给我，老婆说你看好好向人家学学，你看你们工行真是能做些啥都做不了对吧。然后他还很不服气地给我发了个消息说，你看我们这个在那个这上海的这个 AI 大会上，那个积极参与什么出着什么东西，我说这个就是都是这吹牛的这个东西，你那个都是都是那个搞些什么花样，然后外包出去做就吹个牛，做政绩工程。你看人家至少这个东西还是做了很多实事，至少从这个 PPT 的角度，我觉得绝对拿得出手的。讲得是讲内讲得很好。然后里面的内容我觉得坦白讲是在这个领域里面我觉得有一定的鄙视链我觉得银行是处于鄙视链的比较下游的，因为银行的历史包袱非常的重，真的非常非常重，我觉得祖龙可能知道，然后我毕业的时候差不多真的很有可能去银行的这个，因为都是银行体系的这个子女，来坚决没有去觉得这个实在是。他们这个怎么讲呢？不讲了。

带佬 34:46 

然后所以他就很，而且他这个里面就很怎么，很坦白地讲了很多东西，比方说他上来这个图，比方说现在他理解的就是说在 it 里，在这个 it 应用这个架构的里，领域里面就中台这个领域里面的一个发展程度是什么样子的然后一般会是最早的单体服发展到这个面向服务的架构SOA ，然后包括ESB ，企业服务总线，再加上后来的微辅，然后他这里还只写到微辅还没有写到预约深了。但当然他后来也是说他们其实现在银行反正有的是钱像中兴，反正也不差钱。然后他们其实现在他是很先进的，他们也和各种阿里，华为，大家都是有很多的合作，他最后也圆了个场。

带佬 35:31 

然后他很坦白地讲说他现在的银行，他这里应该后面还有就是云原生的，就类似于现在小鹏我们就大厂在做的一些事情，包括我们在做的一些事情。那他很坦白地讲，现在大多数银行处于这个阶段，处于 SOA 和微服务的这个阶段不要笑这个事情是很正常的一个事情。我理解的银行就是处于差不多这个阶段，大部分银行我估计还是偏向于就是这个阶段，然后后面估计都没有再看。有可能因为银行的体系真的历史包袱是非常非常重，而且它的不是那么好迁移的。然后它的痛点它的痛点就是烟囱一个一句话一个词就能概括烟囱式的系统结构烟囱什么烟囱式系统结构。大家知道工厂就一个个烟囱烟囱的结构就是什么呢？就是第一个特点就独立每个就是一个烟囱自己烧自己的火，自己冒自己的烟然后下面是有关联吗？这些烟头之间会有关联吗？当然明显知道是不会有任何关联，基本上没有复用可能。

带佬 36:39 

然后而且银行有一个很重要的特性，基本上就是一些员工然后带着外包去干活，基本上都是外包做的。这也就导致说一个很大的问题，就是说很多时候你很难，你即使想做融合，想做贯通把这个因从贯通起来，很多时候也是很难的。然后因为它不是个技术问题，很多时候不是技术问题，而是政治问题。 OK 然后那他后面讲了一些技术状态记录不讲了，反正就是都是差不多的一些东西看看。好 OK 他现在想做的事情，就是他的蓝图想做的事情，就是他这个你看这样的一个融合之后，你看是不是就和我们现在所经常去讲的或者说经常所理解的这个中台的体系就比较相似了。

带佬 37:35 

最下层是技术中台，类似于前门讲到了提供基础设施基础能力的一些门，一些东西包括 DevOps 一些东西。在上层就是两块比较实质一点的那个功能性的中台，一个是业务中台，各种各样的业务，领域性的业务，一块是那个数据中台管数据的再上层就是我们前端用我们我们我现在称之为用户端。那我们其实现在的从我们的现在纠风给大家整理的以及说我们最近反复在给大家讲的其实也是这么三层，用户端基建，我们的服务层其实也是这样。但是我们的服务层其实我们的服务层其实也是包括有业务和数据。

带佬 38:14 

其实大家可以看到从这个架构角度来讲的话，其实都是差不多的中台架构会有一个好的地方，就是这个会上会看到非常多的类似这样的图。然后你可以通过这些不同的企业和不同的专家的交流，你可以来 confirm 或者说 confirm 自己的做法是对的还是错的？像这个会参加完你就会知道说基本上大家都是大同小异的，这个思路基本上就是一致的，甚至说在基建这个层面会有一些差异的。相对来说技术差异的层面其实大家理解是比较一致的。在目前的角度在云原生出来之后的角度，那他的目前是他这么个理解，包括他的怎么去划分这些领域，这个其实是没有什么特别的。然后他们对这些内容进行了很多的梳理啊，啊我觉得也现在写得比较好。然后业务中台和数据中台怎么做一些关联，然后包括你看数据仓库，数据湖 data lake 对吧，这些专现在比较热门的名词你看一个都不会少。

带佬 39:18 

然后技术中台怎么来思考技术综合的布局什么？其实基本上下面 ASR 上面 PaaS 基本上这个也都是差不多的，但是它这个是在构想阶段能做到这一层，我觉得还是要非常强大的推动力去做。然后真正想我觉得这个整个 PPT 包括里面的一个亮点是或者说值得我们学习的。其实这个我觉得是，那天就在群里想，我觉得我们后面要把这个东西补上。他这里讲了一个事情，就是说我还强化流程。然后这个东西就是你不单单是开发一个业务服务，然后你开发出来这个服务，然后你可能还要去考虑说他是怎么流转，他怎么能通过架构团队、前端团队、中台团队这几个团队之间的互相的作用，把这个东西真正地能够去贯穿好，让大家一方面让大家使用起来，一方面你使用之后你要有维保的然后你可能他的服务有到了一定阶段，他要退役的。

带佬 40:23 

那在这个过程中各个团队应该是怎么相互配合，相互支持然后形成一体化的我昨天还在和静静讨论，说其实我也说到说我们那个我们的研发测试和运维真的是一根绳上的蚂蚱，它是非常的关联性很强的，应该是一个有关联性很强的一个有机的整体对吧？那其实从我们现在的角度来讲，我们有很多文档，然后有很多这个技术点上的文档。

带佬 40:53 

其实关于这个的流程的思考研发流程的思考，包括我们有一些上语音的流程，包括我们有些上线的流程。但是在就说一个服务从一个服务出身到他退役，也就说他这个使用过程中，他这个整个这个生命周期完整生命周期的一个思考，好像我们现在还没有，然后我觉得他这个图画得很好，倒不一定完全适合我们，但是说我觉得还是很好，包括他的服务注册新增支持这个思考，我觉得是我们现在还没有做的，或者说我们即使其实有一类似思考，我把它没有把它沉淀下来，变成一个规范或变成一个能够和大家都去讲，然后让大家形成一个理解一致的东西。那这块我觉得后续我会去把它补上。然后的话和静静和大家一起去讨论，然后把它形成也是内部内训的一个重要的资料。我觉得这个是很需要的，流程上的东西那其他就不展开了，其他其实都差不多了，然后也真的没有什么银行也没有这块，也没有什么特别能够拿出来炫技的东西。

带佬 41:57 

但是整个 PPT 我听下来，这个图我觉得从这个图上我是感受到他们有真正至少有一些人是真正在思考这些问题，然后有一些实际的想法。在这里我觉得很好也是推荐大家就是说其实在思考我们的业务的过程中，很多时候一方美，流程很重要，大家知道一方面就是说其实大家也可以扩展一下边界。能够把自己这块领域的流程扩展到和其他的相关的兄弟团队的一个流程，怎么去把它梳理好然后把它规范下来，然后形成一致的一个思想，然后去做一个后续的实施和推动。我觉得这是一个很重要的一环。

带佬 42:41 

OK 这也是我们后续至少针对这块的内容，我觉得是后续我需要去弥补的一块东西。 OK 这是我们中信银行，其实第二块主要是讲这一块一个流程。其实所有嘉宾里面只有他讲到这块，其他人都没有讲到，我听了哪些其他没有听的不好说，时间不太够了，我可能只能到先讲到这里，可能我们下一周也可以继续讲。

带佬 43:07 

我们接下来讲一个神棍公司 thoughtworks 的内容，它这个我觉得是早上早上其实这几个后面三个都是讲的。早上那六讲里面他早上六讲下午六讲，早上六讲里面讲得最好。然后大家可能最不瞌睡了，很热，因为你们开了空调，然后人又特别多然后其实昏昏欲睡，很多人我看都睡着了。然后他这个是真的是拿到现场掌声最多的一个分享。

带佬 43:38 

一方面他是因为 Salesforce 这个神棍公司，本来就咨询公司，本来就是讲概念对吧，能把这概念讲好讲出花是他们的这个我觉得他们KPI，能够把你讲晕了，讲得佩服你对吧，说这个东西讲得真好对吧，这是他们的这个目标，讲的确实不错。但是其实还是很多玄学在里，就是似懂非懂的那些东西在里面。那他从他的标题其实就知道他其实讲的更多的是概念，概念集中的是什么，讲什么概念，就这四个字的概念，业务中台。那再拆分开来就是业务和中台的概念是什么？他讲了一个他的理解，因为这个大会是中台大会，他讲了一个他们的理解，可能是他们的理解，所有 works 理解。 OK 我们来大体看一下。

带佬 44:27 

最后还有 10 分钟我们来把就把这个讲完，我们可能后面两讲看看，分到放到其他的这个时间里面再讲，因为后面还有会好。那比较可惜的是讲他讲这个的时候正好在开那个周峰大家给我们的销售团队讲云脑的会，然后我就边开两个会一起听，然后就这块听得相对有点少，然后可能有些兴趣没有 catch 到有点抱歉他首先就是先对比了一下这个他其实是要上来就要回答，其实整个 PPT 就回答这两个问题，什么是业务，什么是中台？那首先他是讲中台，中台这个概念，他先阐述他们对中台概念的理解。

带佬 45:13 

那这张图是比较经典的，就是关于我们现在整个这个云的发展体系，从什么都是自己搞，然后到 sr 的就平台，蓝色的是自己搞，红色的是别人提供到 sr 就基于那个云提供基建，比方说买虚拟主机到云提供那个平台服务到云提供一些 runtime 包括说些运行时的一些东西，到云直接提供服务当时最火的解决 Salesforce 的模型。

带佬 45:45 

那中台在哪呢？中台应该在这个模型里面应该在哪里呢？他首先提出一种就是说是不是就是说我们其实中台离职是倒退了，因为中台它上面跑的是什么？跑的是应用和数据对吧？那从这个角度来讲，你看和是这层是平的对吧？那它的应用数据它也不是说是和这个 SaaS 一样，它也是由那个云去托管，它是上层应该是自己是定制运维的开发的，它会加入一层这个业务的模板和数据的一些模板性的数一些东西作为支撑，或者说一些共用性的基建。

带佬 46:23 

那它是不是这么一个架构？那从这个架构来讲的话，它中台，是不是一个 SaaS 的一个定向的倒退，先引入这个问题，他们很多讲解的一些技巧其实很多都值得大家学习了。如果大家有同学有机会去社区里面听一些 salt box 的一些讲解，我觉得其实是对 presentation skill 的也是一些提高。其实可能不光可以注重他们的一些内容，很多可以注重他们的一些制作 PPT 或者讲解的一些思路，他们这个都是很熟练地怎么去引起大引罚大家思考。那他说不是的，他这个接下来就觉得说他其实他们的理解应该是他模板这一层应该是和数据应用这一层对齐的，它更多的是提供了一些模板型的泛化的东西，然后再基于这个上面，然后再生成数据和应用的一些定向的定制性的东西。

带佬 47:20 

那从这个角度来讲，他就把这个先拉直了对吧？就是一个中台，就是一个我们事务型的演进，或者换句话来讲，中台不是一个内卷否则从这个角度来讲的话，你可以看成是一个内卷。对吧？我们没有一个发展，而是我们只是基于原来的一个思考，然后我们换了一个方式去讲。那从从他的这个角度的时候，我把这个事情拉直了对吧？那我就是从一定角度，从政治角度来讲，这个东西我没有内卷，而且我这个东西是有提升的对吧？那我这个东西我就站得住脚了对吧？这是开玩笑，然后它就是从不同的属性，然后会有平台部分和应用部分。然后它有这么一个图这块我就在开会没有听得特别深了。然后他的理解就是前面几块大家比较好理解，上面是业务属性越来越高。然后的话特定企业业务参考模型这里就是企业业务的最佳实践，他这里就是他理解的他这里的中台其实不光是我们前面讲的更多，其实技术中台他这里更多的中台其实着重的还主要讲是业务中台，然后最上面层就是个性化的业务的服务，所以这块是和它的这个锁匹配的，中间是把业务的能力抽象出来，再往上是定制化的业务。

带佬 48:35 

这个其实也和大家这两年听到的最开头中台这个词儿火起来的，听到了很多中台的概念是比较相近。那中台要做什么事儿呢？要从去重到复用，从治理到赋能，从技术视角到业务价值驱动。怎么讲，这个业务就深刻地感受到，你看这个词儿你换一个说法，你就会感到说你这个事情瞬间高大上了。其实前面那三个词儿似乎好像也是描述中台的一个比较合理的这个一个说法。然后你换了个词，你就会瞬间感到中台程度就不一样了。好，那接下来就是他开始讲那个什么是业务业务这里就听得比较少了，这里就开会去了。然后讲到这页，这页好像我还是听到的还是有一点那个感触的。就是说它其实就强化来说，业务的概念和领域的概念这里不要混淆，它这里讲的是 business 业务讲的是 business 换成英文的词是 business 然后领域因为我们最近一直在会讲，包括在设计模式的时候会去讲那个领域看驱动的模型滴滴最近是很火的一个东西，包括那天的会上其实有很多人在讲那个滴滴滴的东西。

带佬 50:00 

然后的话我记得是京东的一位这个资深的专家在讲 DDD 的模型，那那那个他的讲到那个领域这块的话，他是想把领域词和业务这个词做一个区分那他举这个例子挺好的，就说什么是领域源自问题域的逻辑特定领域。比方说造手机和造飞机，这两个是完全不同的领域。你造手机的人能去造飞机吗？造飞机的人也不一定会造手机。那这个概念就是个领域的概念，它是一个非常独立非常专注的线条算法计划、统计优化那叫这叫领域。然后什么是业务呢？业务相对来说是源自业务运营的逻辑，相对来说是它是指领域中立。

带佬 50:48 

相对来说我理解是可以被抽象出来，形成一定的抽象复用的能力的东西。比方说他这里提的是卖手机和卖飞机。而在这两个事情上可能是有一定的可以搜销售的，包括说渠道的运营商是说可以是有一定的抽象这样的一些达到抽象的这些能够实现一定的抽象，而不是像前面两个东西领域可能完全是区别非常非常大的在卖这个过程中，这个方向上其实是很多资源是可以抽象可以共通的。他这里做了一个划分，因为我们他后面要讲的我们今天要讲的这个业务中台更多是集中在这样一个领域这样一个范围里面去讲的业务，他讲的这个角度就抽象应该这么讲。后面就讲了一堆巴拉，这个开始搞学情，搞概念的东西了。这个先把一堆用一堆词概念把你砸死啊基本上就是这种，这个就基本上没怎么听到。

带佬 51:48 

然后他就是来讲说那怎么定义业务中台？那回到说把这两个字拼合在一起，怎么来定义业务中啊？那它是一个企业级的业务模式复用的平台，它不是一个能力，它把这个能力我们再把它细化，它是一个业务模式的复用。然后那为什么要建业务中台呢？就又变成说要建企业级的业务模式复用的平台，他就开始接下来又开始进入这个这个开始搞又开始搞脑子的东西了，这个就不阐述了，因为这看我肯定没他会讲得这个熟而且这个也就听过一遍，他这个应该已经是这些比较虚的概念，已经是玩得滚瓜烂熟了，我更多地返回到这一块，就说它对业务中台的定义是一个企业级的业务模式复用的一个平台。它这里比较关键的是首先我要做中台，我要是为了打造个复用赋能，他这个然后同时我们那个角度我们是站在一个企业级的一个层面去做这样一个复用的，这是一个核心。然后那复用的内容是什么？从业务中台的角度，它复用的是业务的一种模式那这个好像和我们目前来讲的中台可能还不太一样，和我们的现在做的一些服务有一定的关联，我们还没有完全把它抽象成就是我们的服务层。

带佬 53:12 

你看我们现在讲的服务层，其实我们提了五大服务对吧，数据、多车智能业务、运营运维那些东西。运营用其实那些东西里面还没有真正地把它抽象成业务和中台。就是如果要按照业内这种抽象方式抽象成业务中台和数据中台这块的话，我们其实还没有专门去做这样的一些东西的一个抽象。因为其实也在于说我们现在的这个业务模式。比方说我们现在对那个有物流这条线，有那个微循环这条线有那些线。但大是大家看到说我们其实对这层业务其实从我们其实整个公司其实可能还没有做更深层次的抽象。

带佬 53:52 

从我们现在的开发的微服务的角度来讲，我们更多的还是一个能力的抽象那你看他的这个能力的抽象其实就是被他现在划掉了这块。也就是说如果你还只是停留在一个能力的抽象，其实你更偏向于就是说你在从技术中台是在想业务中台的过渡的这一阶段，你还没有达到他所谓强化的这个业务中台的这个概念，强化了这个业务模式的这个一个负用的这个概念啊。啊所以是他要讲的一个事情是这么一个点，和我们相关联的一个思考，其实就是这么一个思考。那当然我们也不是说我们一定要去套业务中台和数据中台，因为也不同公司每个部包括我们现在不同的发展阶段，我觉得现在我们也没有必要去套这个东西。但是说大家可以通过这个去理解来说不同人的对业务中台的一个思考是什么样子，以及说其实我们现在其实做的一个东西就是企业级的能力复用平台。

带佬 54:48 

其实我们这块我们也是正在做也是做了也是正在做的一个东西。但是我们没有抽象到他所说的另外一个层面的一些东西其他，然后他就开始要讲方法论了你看这样一层一层他 PPT 其实梳理得很好，先讲概念接下来说我怎么去做这个方法，因为 thoughtworks 卖的是什么？它是一个咨询公司卖的就是方法。那忽悠把你忽悠全了之后，接下来就是我把这个药就要可以卖给你了你有药吗？我药是什么？那就是这就是我的药要 check now 对吧？然后来这个他就是那他从他们的角度来讲，他们对中台的方法论的理解。那我们要有技术层，我们要数据层、应用层、业务层，战略层了，已经上升到战略层了，公司愿景都搬上来了，只要和 Salesforce 相关的，我觉得这个玄一学和神棍的这些东西都是逃不掉的，其实就不展开了。

带佬 55:43 

但是大家可以看一下，其实基本的概念其实都是非常的差不多的，基本上都差不多。好最后就他这个收尾真的是最后这个凤尾就收得很好。最后再来点睛之笔。其实讲到这里，大家都快觉得他已经讲他最后收了个尾，抛出来一个很令人震惊的问题，然后马上又把大家的胃口吊住了。

带佬 56:07 

搞仲裁会死吗？他这里死会指的是死盒字面意义上的死盒，含义上的死。好另外一个含义上，就比方说这个团队会不会怎么样了，所以会不会这个问题。然后他举了这么一个例子，这张图是什么呢？ thats on every ST 知道什么？喜马拉雅山在喜马拉雅山上这么多年，到 15 年上面死的人有多少。然后这个是 sharper 好像是他们那个就是他们那个当地的人，然后大部分都是登山者。你看，登山者死的集中的区域其实是最高的那个区域，最高的登顶的第二阶台阶还是第一第几级台阶的最高的区域。然后大部分死的人是死在那里。

带佬 56:58 

然后为了解决这个事，你看 1957 年中国再次登山时候，特别搬了一架 6 米的金属梯，放在带了第二台阶上然后在中国这一侧，然后北侧就是这个梯子后来被人们称为中国梯也是救了很多人命，或者说现在登山的必不可少的一个东西。那这个和这张图以及说和我们讲的这个有什么关系呢？那这里他想讲的是说，即使当你这个业务发展到一定非常高峰或非常抽象、非常聚焦、非常专业的，这个时候你就功不受功乎一溃，就说最后以及只差一步就登顶的时候，你还是要有一个梯子来助你一把力。就像登山这样，真的已经快登顶了，还是有这么一个复用赋能的一个东西去给到你。那可想而知是说其实从低到高其实中台都是需要的，甚至说当精细化到这么程度时候，中台可能都是需要，他实际上是想灌输这个思想给大家。这个讲得非常的好很点睛，就是说一下子抓住了大家的点和让引起大家的思考。

带佬 58:17 

最后又引入了一段很文艺的这个登山者里面的一段话，把生活改成中台，再去自己再读一遍，理解一遍，然后就圆满的收尾。整个 PPT 讲得非常的一气呵成，非常的好但是就说内容，其实你回过头来会感觉说他讲了啥？好像就讲了几个名词，讲了几个概念，然后你有什么收获吗？去 PPT 做得挺好的，讲得很好。然后其他好像要再理解一下。但是给大家分享这个这一方面是给大家讲讲说怎么这个业务中台大家不同的理解是什么。