本文源自王晔倞在《技术琐话》周三直播上的分享整理，小编通听二三遍，然后采取记忆要点模式整理，没有逐字逐句复制。而且尽量保留老王口语化的特色。老王写原创的时候语言生动，长句较多。演讲往往通过短句增加记忆点，风格鲜明。

我自我介绍一下，我是王晔倞，目前在好买财富。

我也介绍一下好买财富，一家有牌照的全金融产品销售业务形态的公司。

传统企业在技术意识上的现状

对了，我解释一下，什么叫传统企业。当然我不用百度百科的解释。

传统企业，互联网企业相互看着比较奇怪。

我今天讲的也是我的理解，没有标准答案。如果赞同的，点个赞；不赞同的，你就当听故事，这世界原来还有这些事。

传统企业，总觉得自己很“别致”。

比如制造业，总喜欢拿安全说事！

他们认为，互联网企业很奔放啊。

有时候真有那么大区别吗，还是你找的“借口”？

我之前写过一篇“上海技术氛围烂得一B”，还被人喷。上海除了携程、拼多多还有谁，记得住的不是南京路，陆家嘴、自贸区吗？

北京开技术大会，一个专题结束了，讲师往往被包围，干吗？被包围问很多问题。

上海很有意思，还没结束，就有人跑，回家去了。

上海的工资也并没有比北京低很多。

上海的传统企业比较多

一个老板的特性，就是这样。

对了，有人提醒我，宝钢！

一个城市的定位，跟国家战略有关。

比如卖基金，之前在线下卖，现在线上可以卖。这本身可以作为“传统企业”，互联网只是它的一个渠道而已！

对了，你如何告诉你的老板，自己做中间件对于业务有什么帮助？这三个人还这么贵！

说实话，我说不出来！

对了，我想起来一个经典问题：开发和测试的比例问题！

对了，你听过运维的比例吗？架构师的比例吗？

有标准吗？

多少服务器配一个运维？

如果说一个公司一个运维，又如何衡量这个运维的价值呢？

即使你能说得出来，抱歉，我是老板，我听不懂！

我是做业务的老板！

我们的中后台，不仅仅是1+1=2的问题，是一个增长曲线的问题，可能某些的存在就是为了业务翻5倍、10倍的时候才能体现机制。

他们只明白3个人干多少活，6个人创造了多少营收

这是他们的思维模式。

业务出身的老板不懂技术，

于是技术负责人

放弃了，

走掉了。

老板说你们NB了，为啥还宕机呢？

你们不是敏捷吗，为啥还延期呢？

你们不是devops了吗，为啥运维也在增加呢？

你们不是中台了，人为啥还越来越多了呢？

我的经验就是，解释不清楚的，选择不解释。

技术团队作为成本中心，不同企业的发展阶段有不同的使命的。

幸运的是，我都经历过。

初创，业务高速发展期，效率第一，快点上线。质量重点要吗？没有效率重要，凡是钱能解决的问题，或许都不是问题。

业务减缓期，往往更关注质量了。

业务平稳期，成本意识必须上来了，能100人干的活为啥要招聘200人？

微服务落地的发展历程

架构1.0

单体应用时代，可能是最好的时代。

一个war包打天下。

各条产品线，要用什么都是自己说了算，

上线也挺快。

我们看一下单体时代的几张图。

对了，老王又要讲故事了。

电商系统出问题了，6个总监在一起讨论是谁的问题。

电商研发部找了下面的三个团队，三个团队找了质量，质量找了运维。后来大家决定成立架构组，特别复杂的事情都让架构组做，于是架构组是救火队和背锅侠！

既然1.0时代这么NB，为啥还要转型？

痛啊！

1、业务发展，打补丁，if-else越来越多，终究会失控！

2、业务分散，缺少分层，每次测试都all-in。一个大型项目上线，300人的公司，光加班吃饭就来了100多人。

3、各自玩中间件，你玩这个MQ，他玩那个MQ。

总结一下，1.0时代，我们要解决系统问题、业务问题以及架构问题等三大问题。

架构2.0

理论都很有道理，总结一下，单体虽好，扩展却难。

越大越大的war，200人协同，业务响应变慢。

应用复杂度高，有些坑，可能知道的人已经离职了。

错误隔离困难，一个地方挂可能导致整个功能不可用

应用扩展的成本变高，比如我要扩展一下会员，但交易暂时不需要增加更多服务器。

更要命的是，数据库连接是有上限的。

于是，我们进入了2.0时代，主要是下面三招。因为时间的关系，后面我会讲得比较快......

组织结构垂直化，整合了研发、测试、运维变成全功能团队。这样一群人一个目标，一个屁股。

下面这张图就跟很多“大厂”的图一样了哈。最会员的团队，我可能给你4个人的编制，你该招聘开发招开发，该招运维招运维。

组织结构垂直化，看起来很美好，但是有新的问题，还需要对应的配套。

比如：

1、之前几个测试混合支持会员、积分、交易，哪里忙往哪里搬，现在每个团队得有固定的测试人员。

2、小项目迭代轻松了，TL自己安排发布就好，但大项目对于PM依赖变高了，5个功能团队，谁来协调，打架？我们有项目管理部，但项目管理部的职责不同，他们是传统的PM，可能需要去进修！

3、功能团队之间人员水平和能力差异，导致的技术风险和运维成本增加问题。

于是，我们要继续解决问题

中间件独立团队维护，这块的专业性交给他们。

运维单独有工具团队，全功能团队做运维自助化，在更好的流程和工具上工作。

系统运维部负责IaaS，包括机房、网络、存储等等。

项目管理流程工具配套

具体参考下面几张图

这是我们分布式缓存的监控平台

架构3.0

好了，到了3.0了。

IT自己爽了，业务需要爽。更快的支持业务上线！

我们在3.0阶段，面临的问题。

业务老变，快速尝试。

服务的编排，比如我们和基金公司签的折扣在中台服务中定义，而to客户的产品套餐折扣在产品服务这层定义。

逐步进行服务的拆分，微服务化。

逐步形成敏捷文化，传统一些的项目管理部门在今年拆除。

微服务落地的过程中，要注意敏捷文化的落地。

大家可以看一下我们2018年的一个业务架构。

这是偏技术的一个架构。

因为时间的关系，细节不展开。我们AI智能分析进行了服务化，而账户、保险等服务进行了微服务化，通过逻辑编排进行链接。

这是我们在3.0架构下和1.0架构下的效果。

这个数据是怎么来的，是我们总结收集的。

投资我们的公司是联想和腾讯，联想喜欢做“复盘”，我们也用了不少腾讯的东西。

我们从2014年开始，就坚持复盘文化，下面的案例就是复盘的一个具体结果。

今天，我分享的关键点是2个：

1、我们是一家传统的金融企业，传统金融企业老板如何想，技术负责人如何做决策？

2、微服务过程中的组织问题、架构问题、协同问题，更多是问题驱动，过程中的变化

对于具体的技术选型比如是dubbo还是spring cloud并没有涉及，DDD也没有，这些可以在以后的分享中展开。

服务不是越小越好，

对于我们企业，先做好服务治理。

下面是我的联系方式，我是老王，爱健身的段子手，讲故事的IT人！

往期推荐

• 谷歌开源内部代码评审规范

• 我为什么反对用异常做流程控制?

• 13年创业CEO的复盘：20条人生指南

• 羊毛党跑去京东摸了年终奖

• 为什么顶尖高手，都是深度思考者？

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。