李怀根：广发银行研发中心总经理
本文根据李怀根先生在2018云栖大会金融峰会上分享整理
大家好，非常荣幸能在云栖大会的讲台上跟大家分享广发银行的经历和经验。在过去的一年里，广发银行IT研发人员与阿里云、蚂蚁金服及相关服务商的工程师们并肩作战，在互联网架构转型和移动应用重构方面做了一些努力和探索，并取得了一定的效果。
今天现场的各位金融行业的领导、专家大概能分成两个群体，一部分是业务部门的领导，肩负业务转型和业务创新的重任；另外是IT部门负责研发管理工作的领导和专家，或许正面临着如何上云、如何推动架构转型等烧脑的决策。
业务与研发之间的故事，细说起来至少是一个长篇小说，甚至还可能是“武侠”小说。当业务人员评价研发工作时，他们常常会说“慢”，“非常慢”，“几个月前提的需求还没有做完？”，研发人员则回复“需求质量太差，想要什么说不清楚”“总是变，当初需求说明书就是这么写的”。相信现场的各位对如上言语并不陌生，在社会的快速发展下，业务创新、技术创新，包括场景的创新经常会发生，不断变化的业务需求给研发带来非常大的挑战，我们如何快速响应业务变化，快速响应市场需求变得尤其重要。
另一方面不确定性已经是现在这个时代的常态，经常会有换道超车、弯道超车案例发生。不确定性使得业务必须要去试错，那么研发的另外一个挑战就是如何降低业务试错成本。如果业务有一个想法，结果研发说需要两个月的时间才能试出来，那么业务就会望而却步了。如果只有两周呢，业务部门肯定会大胆的进行试错，在不断试错中寻找业务增长契机。所以除了快速响应外，研发的另一挑战是如何降低业务试错成本。
“厚中台、薄应用”架构转型
面对业务的需求，在传统的银行架构下，研发人员即便是“九九六”也显得应对吃力。于是，我们在2017年8月份启动了中台架构转型。
2015年阿里巴巴提出中台战略, 将核心业务中通用的、公共的模块以服务的方式沉淀到中台，整个集团的核心业务能力均建立在这样一套共享服务体系之上，在核心业务层通过共享服务中心实现了统一和畅通。银行其实也一样，有很多能力是基本固定不变的，比如账户能力、支付能力、认证能力等。但我们的产品系统、应用系统是需要随着业务变化而调整的，因为场景在变、渠道在变。变化的部分以业务流程为主，能力部分多数情况下不用变动。
这也是广发银行在过去一年里做的架构转型，过去我们做一些应用系统时，我们会在每个系统里把业务流程、后台管理，用户认证以及用户登录都建设一遍，手机银行有一套，网上银行有一套，柜面系统还有一套。但现在我们单独建设了一套能力中心，它们相互独立，可以为所有产品互用。新的产品系统要上线时，它不需要独立建自己的用户中心，不需要再去做独立的认证中心，也不需要再去构建自己独立的支付中心。
确定架构转型是工作的第一步，关键还是要落地。启动初期，我们首先做的事情是对人员组织架构进行了调整。过去我们做一个应用时，从产品渠道到后台的实现会有一套完整的团队，既有前端也有后端，还有懂业务流程的后端人员。现在我们发生改变了，建立了独立的中台产品团队和中台研发团队，他们负责建设能力，负责维护全行的能力地图，这是在组织架构上最大的挑战。第二件事情，这次架构转型对我们挑战非常大，因为过去的能力和经验几乎完全没有用，我们要用新的方法构建，所以在正式实施任务前我们与阿里合作进行了为期三个月的培训。
架构转型过程中坚持的三个原则：
第一：重要的事情要慢慢的做，要做得稳当。这是第一个原则，我和团队说可以自己制定项目计划，必要的时候可以往后延一个月甚至两个月。如果我们追求速度，为了快点上云，很容易会导致匆匆忙忙就把这个项目的表层工作做完了，但中间的过程会走得并没有那么稳，没有那么踏实。
第二：设计优先。在整个项目开始过程中特别强调必须把所有设计做好，必须先定出设计规范，我们引入了领域驱动设计，这个建模过程比较痛苦，因为要把所有业务部门请来按功能梳理，把问题独立拆分出来。我们以前做项目时，习惯将需求从头到尾串下来，但现在我们要把中间能力部分一个个摘出来，放在不同的问题域里。过去我们做项目、做应用开发最缺少的一步就是建模。这次在互联网中台架构转型中，我们特别坚持了要去建模，要用DDD（领域驱动设计）方法重新拆解整个业务部门。
第三：坚持做持续集成，持续交付。我们引入了阿里云效平台每天做自动化测试，得益于不断的测试与回归，这个工程最终顺利通过，同等体量下的项目多数情况下都会有冒烟的问题。
厚中台、薄应用，这是我们一直在坚持的。整个中台部分分成若干个问题域独立进行建设与发展，同时它又可以被所有的应用去调用，反复使用，避免相同的功能模块重复建设，这就是我们过去在一年多时间一直坚持做的架构转型。
对标超级APP，全面重构移动应用
广发银行有两个App，一个叫做手机银行，注册用户3千万；另一个是信用卡门户App发现精彩，2500万注册用户，日活150万左右，发现精彩每周五都有秒杀活动，秒杀的时候日活接近200万。
在座各位可能都有这个印象，银行App总体的体验没有互联网App好。比如启动比较慢，过去手机银行打开白屏超过5秒钟，而在互联网时代，5秒钟“白屏”的情况下用户基本默认这个App已经“死”了；闪退、卡顿的现象也出现频繁，其实闪退并不可怕，怕的是不知道谁闪退，不知道在哪一步出现闪退；另外还有诸如消息到达率低，导致业务部门做营销活动时不太敢去推送消息，影响业务运营等问题。2017年8月份，在一次新浪的移动App体验评选中，广发银行手机银行App得分排名靠后。当天我在朋友圈里立下誓言，明年一定要把发现精彩和手机银行拿下。
我们在2017年9月份启动移动框架选型工作。在讨论选型原则时，我提出要对标超级App，跟它可以有差距，但要在一个层级上。最终我们选择了脱胎于支付宝的移动框架平台MPaaS，其强大的运营分析能力，客户无感更新，极高的到达率，可以按照时间、地区以及机型多条件试错的性能等都是我们看中的原因。
全面重构，体验至上。手机银行和发现精彩这两个APP体量还是非常大的，千万级用户，百万级日活。最多的时候两个团队加起来接近300人同时作业，75%的业务在手机银行完成，50%分期和交易占比在发现精彩中。我们有两个方案，一个方案是做兼容，对已经“腐化”掉的代码修修补补，少改50%的代码，同时留下50%的“垃圾”。另外的方案是完全重构，原来的代码一行都不用，我们勇敢地选择了重构，用全新的代码设计，一行一行重新写代码。
我们在今年6月底推出了新版发现精彩，经过一个多月后已有85%用户更新了版本，手机银行上周也已经更新了内测版。目前发现精彩（IOS客户端）热启动时间0.52秒，第一次下载冷启动时间是0.86秒，闪退率万分之四。关键是我知道它是万分之四，以往这个数据是无法获取的，该指标与支付宝相当，卡死率（点某个按钮10秒钟没有反应我们称之为“卡死”）万分之一。我们还学了互联网的玩法，第一次在生产环境上进行线上全链路压力测试，过去银行是不敢做的,峰值达到4.5万TPS。
关于转型的思考
两个转型过程讲完了，背后还是挺辛苦的，如果我今天的分享和实践能够推动大家对架构转型进一步的思考，让全行业银行APP用户体验上一个台阶的话，那我觉得还是非常有价值的。
最后跟大家聊聊通过一年来的转型工作个人的感悟：
第一、业务和研发：深度融合、业务敏捷。我们要改变和业务沟通的方式，过去追求高效率、专业化做事情的方式。现在变化太快了，必须让业务和研发人员深度走到一起，要做业务敏捷，深度融合。
第二、软件研发唯快不破，速度决定成败。只有把整个研发进程放在“快”这个要求下，一切以“快”为目标，快速反馈，快速响应，才能够把环境供给、技术能力等有缺陷的部分暴露出来，及时加以调整。
第三，架构设计要有前瞻性，不建议“够用就好”。现在业务发展太快了，今天的一个架构，明天可能因为一个新的业务需求，就触及到了架构天花板。过去我们有一个零售信贷系统，它针对线下抵押贷款业务绰绰有余，但是当接入到互联网渠道，通过互联网获客时，这个系统就难以支撑。架构设计一定要有前瞻性，不能抱着“够用就好”的态度。
过去的一年里我们不停地做改变，改变需要勇气，也需要坚持和正确的执行。我们不回避矛盾，重构了互联网服务中台。我们敢挑硬骨头，换App框架，重构最重要的应用。敢于对标，就是要追求极致体验。过去我们经常为了省下开发成本，用所谓混合开发的模式，今天我们把App里转账、查询的功能主页以及登陆、注册等高频环节全部做成了原生，追求的就是用户体验。
我们以终为始，坚持目标，相信才能看见，在相信和看见之间是一段漫长的坚持。我们要像发明工具的人那样使用工具，我们在与阿里巴巴的合作中请来了阿里中台事业部的人来给我们做咨询，我们要学习他们自身的使用方法。开源是一个低门槛，高代价的事情，我们要培养基础力量，一定要把它研究透。
在过去一年里，我经常用一句话鼓励我和自己的团队，《艾丽斯梦游仙境》里，红桃皇后说了一句话：在我们这里只有不停的奔跑，才能留在原地！
原文发布时间为：2018-09-29
本文作者：未若
