本文源自王晔倞在《技术琐话》周三直播上的分享整理，小编通听二三遍，然后采取记忆要点模式整理，没有逐字逐句复制。而且尽量保留老王口语化的特色。老王写原创的时候语言生动，长句较多。演讲往往通过短句增加记忆点，风格鲜明。
我自我介绍一下，我是王晔倞，目前在好买财富。
我也介绍一下好买财富，一家有牌照的全金融产品销售业务形态的公司。
传统企业在技术意识上的现状
对了，我解释一下，什么叫传统企业。当然我不用百度百科的解释。
传统企业，互联网企业相互看着比较奇怪。
我今天讲的也是我的理解，没有标准答案。如果赞同的，点个赞；不赞同的，你就当听故事，这世界原来还有这些事。
传统企业，总觉得自己很“别致”。
比如制造业，总喜欢拿安全说事！
他们认为，互联网企业很奔放啊。
有时候真有那么大区别吗，还是你找的“借口”？
我之前写过一篇“上海技术氛围烂得一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人！
往期推荐
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。
9619
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
