关于你我贷技术这六年！

几年来，伴随你我贷成长，技术队伍也在不断壮大，期间也沉淀下来很多人和事，在这里回顾历史，留存记忆，是为了更好的前行。
很多伙伴经历了你我贷系统的 1.0、2.0、3.0 和目前的4.0时代，取得的成就离不开大家的付出和努力。
       技术人，始于技术，而不止于技术。业务看得是今天，技术着眼于未来，为建设出更先进的系统，更优秀的团队，需要我们继续——并肩前行。
下面这段为摘录：
       世界上最恐怖的事，是拿自己的时间去见证别人的梦想成真！
       最悲哀的事，是自己不敢尝试还去嘲笑身边为梦想而奔跑的人！
       最后不得不承认：
       自己一生最大的失败不是跌倒，而是从来没有实现自己梦想的勇气！
       人生不是我们做了什么而后悔，而是因为什么都没做而后悔！
       一个输不起的人，也往往嬴不了。
       你要明白一件事：
       财富是你的，自由是你的，
       未来精彩的生活也是你的！
       机会永远是留给有规划、有信誉、有责任心、有远见的人。
       人无远虑，必有近忧！
       机会永远留给有长远眼光和远大有目标的人！
       成功！一定是信心行动坚持的结果！
       一群人，一件事，一条心，一辈子！
       作为兄弟与所有勇者共勉！
       胜则举杯相庆，败则拼死相救。

在写这篇短文期间,新闻报道了86版《西游记》总导演杨洁逝世的消息。新闻中说：杨导从1982 ~ 1988年，历时6年时间拍摄了中国的首部神话电视连续剧《西游记》。当时的拍摄条件比较艰苦,整个过程中只有一部摄像机，演员片酬一集也只有几十元钱，事实上她拍摄《西游记》遇到的困难比唐僧去西天取经时遇到的81难还要多得多。但是所有人都怀着对艺术的追求完成了这个巨作。当时他们开始拍摄的时候，可能根本没想到，这部巨作会走红三十多年，代表着一个时代的人的回忆。当又一次听到片尾曲《敢问路在何方》的时候，让我不禁觉得，这首歌也许在表达着《西游记》拍摄过程中每个人的心声。

       西游记的故事其实反应了我们每个人的人生。当我们有了一个远大的梦想，明确的目标之后，可能并不一定可以找到一条通往成功的道路，也不一定会有导师来指导我们该如何到达梦想的终点。而我们却不得已每天受迫于生活或社会环境中的压力向前迈进。有的人可能遇到了机遇而迅速找到属于自己的成功道路，有的人可能碰巧正好选择了一条可以通往梦想的道路。还有些人虽然自己不知该如何前进，但跟着有志之士一起结伴通往成功之路。当然还有另一类人，他们虽然非常渴望成功，可或是浮躁，不断改变前行的方向，到后来才发现绕了一圈又一圈,又回到了当初那个面临选择的原点。或是过于懒惰、怯弱，每每遇到困难、瓶颈就像遇到了一座大山,挡住了前行的路。我们如何才能像《西游记》里的唐僧师徒那样，克服千难万苦、矢志不渝地到实现自己的梦想呢？

       首先要有一个坚强的信念。思考一下自己上班是为了什么？其实人在金钱等物质利益前面是非常脆弱的。如果你只把赚钱作为自己的信念，那么就很容易迷失方向。我们需要一个强大信念，去支撑我们每天在工作和生活上所付出的努力。比如可以考虑如何通过工作来成就自我，如何通过工作让自己或同事感到自豪。这是一种因精神层面的快乐所形成的信念。等到我们老了以后，在晚辈或子女面前，讲述这些经历时，仍然会感到快乐与自豪。第二个是坚持。我们的理想越是远大，在实现理想的道路上就会有更多的困难。如果你并不知道自己走的道路是否可以实现理想，而路上又遇到了很多艰难困苦，需要付出大量努力的时候，你还会坚持下去吗？或者已经付出了大量努力而没有取得进展的时候，是否应该继续坚持？让我们学习一下毛竹。毛竹种下以后，4年只能生长3厘米。但是它的根却在土壤里延伸了数百平米，打下坚实的基础之后，毛竹从第5年后以每天30厘米的速度生长着，一个月后就可以长到十几米高。我们需要每天做出一点量变，并一直坚持到可以发生质变的时候。第三个是团队。如何实现梦想，大多数人都会迷茫。其实，有一个捷径就是跟随着一个朝气蓬勃、快速发展的团队。当我们在团队中相互协作、共度难关，实现一个又一个战略目标的时候，我们离自己的梦想也越来越近。也许在团队的发展过程中，自己的小目标或理想和团队所赋予我们的工作会有所冲突。但是一个好的团队，只要员工拥有坚强的信念、可以坚持地做好本职工作，总会有一个合适的空间让他发挥才能，或者自己会在团队中找到更适合自己的位子。

       敢问，实现梦想的路在何方？路就在我们每一个嘉银人的脚下。我们只要怀着坚强的信念、跟随着嘉银团队、坚持脚踏实地的向前迈进。敏捷高效、持续改进、积极创新、打造出极致金融体验的你我贷平台。终有一天，嘉银团队取得成功的同时，也彰显着我们每个嘉银人身上的辉煌。

记得刚来嘉银的时候在嘉友杂志发表过一次访谈，一转眼，两年半过去了。这两年半P2P行业风风雨雨，我们一步步迈着坚定的步伐向前。
先看技术中心的发展。这几天我也在读一本《淘宝技术这10年》，很有感触，如果不是有业务驱动着，技术其实是很难有自动的发展的。淘宝从最早的一台服务器，PHP/MYSQL开发的网站开始，经历了数据库升级到ORACLE，机器升级到小型机，但如此昂贵的IOE架构也很快撑不住，于是又请来SUN公司的高手帮助将系统从PHP改造成JAVA，但外来的和尚能干的也有限，最终还是靠淘宝自己人，一步步把服务化，分布式，开放平台，中间件这些体系搭建起来，并在多次双十一的洗礼下得到验证和进一步发展。（建议所有技术线同事必须读一下）。

       你我贷的发展虽然远没有淘宝那样汹涌澎湃，但经历的历程却在很多地方雷同。我来公司之前，你我贷已经完成了从1.0PHP向2.0JAVA的演化。后面经历了你我贷3.0的数据库的重大升级，目前技术中心投入将近一半的资源在为你我贷4.0奋斗，4.0的根本思路也是将各种服务做细做独立，以及数据库的拆分治理，从而能让各业务更独立。可以说我们是一边顶着业务压力努力赶着业务需求，一边加班加点耐心分析重构。这两年多公司业务也有很大发展，首先是线上投资业务的快速发展，还记得我刚来的时候，一次周末严总打电话问我什么时候一天能有200万投资额，可去年双十一我们单日交易超过了1个亿。在那一个亿发生的日子背后，我们的系统做了极多的调整，同时还要兼顾线上借款的压力，他们也在做促销 – 说到线上借款，那基本上是以一年的时间，趟过线上投资3年走过的路，而且现在每天的注册量更是投资的数倍（从资金面看这是正常的，一个线上借款人平均可能只有小几千元，而投资客户很容易就投资个数万）。对系统而言，1万和1千都只是一个数字，所以线上借款带给我们的压力是剧增的。一个不小心系统故障，谢飞总肯定又在默默扳手指算损失了。

       两年半以前我刚来的时候，我了解了数据的量后就没有太多投入大数据建设，也没有刻意扩展算法工作。因为巧妇难为无米之炊。但今天不同了。我们的大数据集群已经真的很大：-）数据中心除了支持各部门的业务BI报表外，也在推动着各研发团队的离线计算，从而让我们生产库减压。另外数据中心也在努力做着产品化服务化的输出，自建的数据采集系统，反欺诈反羊毛党系统进展顺利。另外我们也在业内热点的人工智能，区块链领域积极投入，希望在机会来临的时候，做个有充分准备的候选人。

今年技术中心的主旋律很清楚：
1） 做好你我贷4.0重构，为后面2-3年的业务打好基础；
2） 做好合规改造，为你我贷生存拿到船票；
3） 做好业务建设，让我们有尊严；
4） 做好创新研究，让我们有未来。
希望大家共勉！

回想起最早接触P2P这个概念，是从新闻联播里来的，那个新闻介绍了一种新的小额贷款模式，这种贷款模式和银行里的不一样，是一种纯线上的借款服务。在此线上贷款的用户，普遍借贷资金在几千元。如果违约，网站会公布借款人的信息，如照片、姓名和身份证号。据介绍，在此网站借款的用户主要是短期资金周转，或者为了几千块钱不想麻烦亲朋好友，向熟人借钱，在人际关系处理上会遭遇麻烦。这也是最早的P2P发展雏形。那时是2012年初看到的新闻，而后幸运的是，就在7月，我通过周格的介绍进入到了你我贷。

       刚进你我贷，从人数上感觉不像是创业公司，那时员工总数在350不到，但仔细看下部门，人员占比主要在贷款部，理财部和客服部，后勤部总的加起来50人不到。你我贷成立于2011年6月，在P2P行业里算得上是比较老牌的了。相比起早在06，07年成立的P2P，严定贵先生把握的时机是比较好的，以及下的决心是非常大，这次创业是把自己居住的房子卖掉，才有了启动资金，也是严定贵先生的第二次创业。也许这一切，对于奔5的他来说是对自己人生经验的运筹帷幄吧。

       为何说严定贵先生把握的时机是比较好的呢？个人认为，因为互联网的金融元年是2013年， 严定贵先生提早了2年进行布局，做好了充足准备，打下了扎实的基础。但如果过早的进入，会非常难熬，一方面是没有足够多的业务来维持企业的生存，另一方面是没有风投会介入进来。
       提到互联网金融元年，这一年发生了很多事，比较典型的是，余额宝在6月17日正式上线，而在18日一天就突破了100多万，这个数字对于当时是非常惊喜的，现在可能对于你我贷来说也许只是个零头而已。而对于余额宝背后的天弘基金来说，就是风口上被吹起的”猪”，被互联网+金融这个概念吹起。而被这阵风吹起之后，对于原来在国内的公募基金里排不上号的天弘基金来说，截止2016年12月31日，在规模上三年蝉联行业第一，达到8450亿元。这就是互联网带动传统行业的力量。

在IMO上，吴老师发了个信息，”小奚，快来下会议室”。于是，我按IMO上的地址去找会议室。兜了一圈才找到，因为我们刚从科技大厦搬了新的办公地点——宏嘉大厦。刚进到会议室，他们灯也没开，里面站着的是吴老师，周格，APING。看他们发愁的样子，估计是有重要任务要商量怎么去安排。那是2012年11月的样子，来你我贷也2个月了，期间做了一些销售团队通过不同的业绩计算出提成，最后结算出薪资的系统开发工作，以及通过富有平台，做了些代收代付的开发等等，对系统里面的一些主要的数据表有了一定了解。这次要开发的功能是债权转让，即针对线下理财会员合同到期需要转让债务标的的功能。那时债权转让相关的借鉴网上查不到，而整个会议讨论下来，只获取到了他们的想法，而具体的细节，如流程，程序的设计，如何展现需要会后自己去琢磨，回想起当时，一个人对现有系统及自己的方案闷头研究了3天，最后跟吴老师确认这套线下理财和债权转让方案的可行性。

在细节及一些算法的讨论确认后，便着手开发了起来。因为当时要的急，我把债权转让分了两部分开发，一部分是1次转让，第二部部分是N次转让，难点在第二部分。于是我先把线下理财和一次转让先上了，N次转让等等再进行开发。由于当时人员不多，吴老师说，这几个任务先开发一下吧，N次转让需要理财产品最低3个月到期后才会进行2次转让，这个先放放。于是开发起了一些其他的棘手任务，开发到4月份的时候，发现这些棘手任务永远也开发不完，完结一个又来一个。而我这时掐指一算，离上次债权转让上线已经2个多月过去了，感觉心慌，不对劲，去数据库查了下最近一次的2次转让是什么时候，查完一脸懵逼，是5月3日，好吧，节日没了。于是我赶紧通知吴老师，手上的还未开始开发的任务需要往后压了，否则来不及开发N次转让了，而这个N次转让，我还没开始想怎么个实现，并且他比1次转让在算法实现上复杂很多。但最终还是赶在了4月29日上了线，当时还没有测试，所以都是自测的，其实自测才花了1天吧，尽管自己测试的对情况有一定了解，但心里还是比较慌，因为通过这个功能，每天会有几十，几百万的资金自动流入到不同账户。

所以我的五一并没有过好，失眠了几天，躺着一直在思考有没有偏差的细节，以及如果出问题，该如何解决。过完节，5月4日，我赶紧查看债权转让监控数据，因为这是昨天开始就进行转让了，如果出问题，会出现两种情况，一种是理财合同到期后，总金额不对，还有一种就是到期后，没法结算。但幸运的是，这些情况都在用户无感知的情况下，都被我及时修复。当时我的解决方案是，我每天会把所发生的转让数据检查过去，发现一个问题，解决一个问题。到后面转让的数据越来越多，我每天就坚持花三个小时抽随机抽里面的一部分数据进行验证，像这样坚持了3个月，其实一个月基本就趋于稳定，主要是不抽查这些数据的准确性，心里就不踏实。尽管已经快过去了4年，但那段岁月还是印象深刻。

       总的来说，在任何一家公司还处于创业期的时候，各项资源都是匮乏的，需要每一位团队成员都要有强大的主观能动性，公司就像自己孩子，要有不求所图的奉献。而在工作原则上，讲究的是要新，要快，快速迭代，从而对商业逻辑能得到快速的验证。

你我贷最开始的网站并不是自己开发的，也就是PHP 1.0之前，是吴老师找了一个用PHP写的开源CMS软件自己进行的二次开发而来。而CMS系统主要的模块有，用户管理，文章分类管理，文章管理，网站框架管理等等。因此对于最早期的P2P官网来说，只需要在原有的CMS系统的基础上，前端增加支付提现，投标，标的显示等功能，后端开发代收代付，借款产品，理财产品，进件，审核，发标以及其他一些企业日常管理的功能，如薪酬核算，报表等等模块。

       企业从成立到过了半年，公司人员从几人到了几十几百人，IT部的建设迫在眉睫，那时吴老师已经招募了APING，从事PHP的开发。由于基于开源CMS开发的P2P网站，在代码的隐秘性上不够安全，于是就开始开发你我贷的1.0版本。当时APING用的是ThinkPHP框架开发的你我贷1.0，差不多这个版本沿用了2年。后面公司挖来了李盛超团队，想做第三方支付的业务，但因某些原因没有做成，就整合进了PHP团队。此时大家开始着手考虑，如何借助于JAVA语言使系统更为强大？起初的方案是这样设计的，CodeIgniter+RPC+Spring+Ibatis+MYSQL架构的，也就是说，MVC放在PHP的CI框架中，做业务开发，而JAVA则作为底层组件及数据持久化，对外提供服务。这样既能体现PHP快速开发的优势，也能通过JAVA保证系统的稳定，而PHP系统部署的时候，是不需要重启服务的，只需文件覆盖就行，用户无感知，因为它是解释性语言。但后来这种方案被否决了，主要的原因是PHP开发人员实在太难招，而JAVA开发人员相对就多很多。以及两种语言的开发团队，在人员调动上也很难管理，于是就干脆全部由JAVA代替。

       写到这里，也许会感觉公司在技术方面折腾了不少，但实际上，真正的折腾才刚刚开始，后面你我贷系统的2.0，3.0，4.0，每个大版本的升级，都经历了诸多事情，背后都付出了巨大的努力和汗水，也许到这里才是一个全新的起点。

在2014年7月初的时候，也就是2.0系统上线没几个月，我们发现在P2P行业里开始出现了一些新的业务平台，有基于IOS和Android开发的P2P客户端。还有些P2P平台直接基于微信公众号，业绩增长量也相对不错。于是我们意识到，随着智能手机飞速发展越发普及，移动浪潮不可阻挡，而在用户的使用率上，手机端也在逐步开始超越PC端。

由此，公司决定快速启动移动端项目，分为IOS,Android,WAP及微信公众号四个方面。WAP和微信公众号可以基于网站组进行开发，但IOS和Android这两块的渠道，我们并没有开发工程师，无法展开。而这个领域对于我们来说是全新的，于是我们找了家外包公司，让其先开发，快速推进进度，让外包人员驻场在我们公司进行工作，而对于与APP交互的服务端架构和模式，通过自己的调研，采用了银行支付的模式，从而快速的完成了APP1.0和2.0的工作。

2.0上完后，发现APP的前景很不错，加紧开始了3.0的筹划。3.0开始也是准备使用外包团队，后来由于周期长价格高等原因取消了外包，随即决定自己研发。自己研发首先要有相关的人才。在王剑同学的引荐下，顺利招到了两位专职移动开发：Android开发工程师谢红云和IOS开发工程师唐卫。没过几天，IOS工程师顾颖炯也加入了进来。当初还没有单独的移动部，这几位成了研发部最早的移动开发同学。他们加入研发部的第一件事情，就是从外包手里接过源码，梳理业务流程和相关逻辑。

3.0的需求正式提出来了，说干就干。在领导的强力推进之下，3.0团队走进了小黑屋，开始了996的工作节奏。王剑负责3.0版本的进度控制，潘环是产品经理，李宇峰负责UED，服务端由陈楠和胡海浩负责，客户端由上述3位同学负责，测试人员则是由施玲艳和辛凡萍担当。在明确了分工之后，研发工作就如火如荼的展开了。3.0版本加入了很多功能，APP的架构也进行了重构升级。整个APP的开发和测试过程中，各个模块的同事都很给力，大家团结一致向前冲。功夫不负有心人，一个月之后，3.0的新版本如期上线了。新版本无论从视觉效果还是功能体验都让人眼前一亮，为了移动端理财打响了第一枪。

    随着公司团队的不断壮大，单打独斗已不适应业务的要求。在技术中心高层的支持下，2014年年底移动部正式成立。招聘工作迅速展开，从最初的2、3个人扩展到年底20多人的规模。人员上齐备了产品、开发、UED和测试人员，俨然一个小型创业团队，可谓兵强马壮。3.x版本可以说是相当成功，但也存在一些问题。比如iPhone已支持了Retina屏幕且推出了不同尺寸的机型，需要做特别的适配工作才能支持更好的视觉体验。另外，3.x的外包代码比重仍然很大，其内部结构已落后于最新移动端技术的发展。因此，部门接到的第一个工作任务就是完成理财APP4.0的重构。似乎是老天有意要磨炼我们的心智，那段时间大家走了一些弯路。主要原因是，几乎全新人的团队，在没有深入理解业务的情况下，急于推陈出新。另外，过于追求APP展示的酷炫效果，没有真正从用户的角度去考量他们的真实需求。感到欣慰的是，虽然UED稿变来变去，开发人员并未自乱阵脚，持续不断夯实新的APP技术架构。

船小好调头。在公司领导的推动下，部门进行了及时重组。产品和UED归入了业务部门，测试组回归了测试部门。移动部保留Android、IOS客户端开发和服务端开发团队，专注于APP的技术研发工作。随着团队磨合越来越好，4.0的重构工作逐步走上了正规，大家的热情再次重新被点燃。还记得逼近deadline最后一个月的时候，冯总亲自抓4.0项目的进度，每天早上组织例会碰进度抛问题。那段时间是项目进展最快的时期，对后来4.0的成功上线起到了重大的作用。

4.0的开发前后持续了小半年的时间，最终得以成功上线展现于世，离不开每一个小伙伴的全情投入。全新的视觉，全新的交互，全新的技术架构，同样也是全新的用户体验。
Android在引入了Volley的基础上重新设计了网络层，能够使用简单的API即可做到异步的网络的请求与回调。采用Wiki做为接口规范及验签规则的记录工具，在后期版本后逐步剥离出了数据库访问模块，JSON解析模块，数据加密及验签模块，数据缓存模块，日志记录模块等基础服务模块。在基础服务模块上我们又开发一系列的同用组件如：手势密码，社交分享，埋点统计，服务推送等。

IOS引入了CocoaPods作为第三方包管理工具。从应用层中分离了Library层和Base层，让开发人员更专注于业务逻辑的开发，也为后期多APP的快速开发提供了便利。重新封装了网络模块，与服务端约定了新的接口规范、验签规范和JSON格式规范等。视觉上，新增了iPhone各种机型的适配，抽离了字体、颜色和图片。此外，通过Xcode的编译模式和脚本实现了测试环境和生产环境的隔离，从而避免了手工切环境带来的风险。其他大量的基础类库、基础控件的封装也都在这一时期完成，为后续的快速迭代打下了坚实的基础。

今天的移动部已逐步走向成熟，我们的产品除了理财APP，还包括信贷APP、电子e签APP等。我们的团队也按照产品做了划分，大家各司其职，组员关系融洽，合作顺畅。2017年，移动测试组再次加入移动部大家庭，团队焕发第二春，随时准备迎接新的挑战。在技术上，我们通过对HTTPS的支持、会话的改造、安全键盘的采用、第三方加固方案的引入等措施进一步完善了APP的安全性。这对于我们互联网金融类的APP来说至关重要。在产品上，我们不断完善APP的业务功能、页面展现和交互，让用户可以得到越来越好的产品体验。我们集成了第三方监控SDK，随时随地监测APP的健康状况，悉心关照用户的使用感受。目前，理财IOS版本的崩溃率维持在0.05%左右，理财Android版本的崩溃率也低于0.1%，整体达到了业界先进水平。很幸运，我们处在一个移动的时代，移动端正成为流量的主要入口。同时，我们也深感肩上的责任重大，守护好我们的入口、输出高品质的APP、提供极致的用户体验，为公司的互联网金融业务健康持续的发展保驾护航，我们义不容辞。

再回到2014年下半年，除了进军移动端领域，你我贷的2.0系统也开启了一段不寻常的历程。由于你我贷在业界的影响力在不断的扩大，在安全，性能及数据量这几块问题开始逐渐变的越来越突出，尤其是安全这一块。越来越多的黑客开始瞄准你我贷，在网络上，发起各种攻击。如短信，当时一晚上被刷掉几万元的短信等等。为了加强软件安全这块能力，和大超哥面试了好几位安全工程师，最终选定了冯老师，冯老师在系统安全方面，挖出了大量的安全漏洞，在安全层面上提供了有力的保障。

自从短信被攻击后，CC攻击，慢链接攻击，sql注入等等。而CC攻击在高峰的时候达到了日200多万次，当时没有完善的安全设备，只能通过shell脚本统计出高危ip，配置在ng里面拦截，量大时根本处理不过来。直到2015年，网络安全攻击还是没消停过，每次做活动都会被网络攻击。而且现在日常攻击次数也不低20w之下。

2014年双11活动时，系统已经慢慢的变得比较稳定了，但于此同时也经历了最大的安全攻击，单ip攻击流量接近20G，致使ip被封，吴老板临时购买了网络流量清洗才得以缓解，当年的三国活动也取得的不凡的影响。为了避免不必要的猜想，当时DBA和老白都没有参加活动，看到活动能顺利结束，心里也是非常高兴的。

系统逐渐稳定了，但随之而来很多问题，数据库成了最大的瓶颈，基本上每周都是挂两次以上，因为索引问题，慢查询等，禅道里曾经挂了几十个慢查询等待解决，业凯来到之后，很长时间都在专门处理慢查询，以便解决性能问题。祸不单行，当时CRM库因为严重影响主库性能，只能从主库切走，但是因为当初还没有服务化的概念，只能通过数据库同步完成，因为数据量增长较快，数据量越来越大，经常数据同步不能及时完成，每周至少影响呼叫中心业务两次。

2015年初，即将过春节，老肖把徐杰，杨严飞叫到我那，让我们对机房扩容，要满足未来三年的业务需求，最开始要求我们两三个月，我们说完成不了，后面经历各种讨价还价，最终到8月才完成机房扩容。并且实施了机房搬迁。 2015年5月左右，初步探到吴老师口风，于是和老白立即商量，痛定思痛，决定切换数据库，在当时人数并不充足，还要满足大量需求的情况下，老白抽调大量人力开发数据库切库事宜，工期短，劳动量，大家付出很多很多。并且通过etl，对近200多G的几百张表进行数据库转换，当时一张表一张表的做etl，那个相当痛苦啊。

2015年8月，徐杰、杨严飞、唐红春在机房，老白、业凯和我在公司，两个部门相互配合，前后将近40多小时不停工作，基本上完成了数据库切换，但刚切换结束，并没有达到理想效果，性能非常差，始终找不到原因，冯总也找了自己关系来处理。突然系统自己恢复了，当时也只能怀疑是缓存数据的问题，2016年4月左右也发生过一次，当时小妖刚来，就经历了一次比较妖的问题，始终没有头绪。切库完成后数据单库QPS也从原来500左右，提升到了5000，性能得到了大幅的提升。

完成了数据库切换后，系统无论在稳定性还是性能还是可靠性上都有很大的提升。但是新的问题又来了，系统之间包相互依赖非常严重，常常一个包改动，其它包也是上线，为解决这个问题，又开始了dubbo服务化的改造进程。系统有条不紊的改进，虽然有些意外，但是还算比较稳定。

服务化改造建设差不多了，2016年数据库比2015年差不多增长了10倍，主库从200G增长到2T。整体数据规模达到了30T左右。2016年上半年和老白商量，探讨，从稳定性，可靠性能方便考虑，决定推动微服务化建设。从此进了一个新的里程。

两年半的时间，我们经历了很多很多，也学到了很多，变是我们唯一不变的原则。

在网络安全问题解决完之后，后面直接面临的是数据压力和WAR包依赖这两块最突出的问题。为解决这些问题，2015年下半年开启了你我贷3.0系统的改造。

在3.0系统建设中，主要是两大块：

1、MYSQL迁移至ORACLE

2、进行DUBBO服务化

关于第一点，有人也许会问，MYSQL数据量在上千万的时候快撑爆了，即使你切换到ORACLE又有什么用呢，达到上亿，上百亿还是会有撑爆的这一天。确实，你的理解并没有错，我们切换到ORACLE并不是最终目标，是一个短暂的过程，是帮我们解决当下棘手的数据量随时撑爆的风险问题。但最终我们还是会去IOE，还会切回到类似MYSQL的数据库上，是的，在后面的微服务建设中，我们选用了PG数据库，以及ORACLE，而ORACLE是作为核心数据的存储，如交易数据，会员基础数据等等。以及后面大数据的建设。但是要做完这些事情并非一早一夕能搞定。随意我们对现有系统的MYSQL数据库进行改造，切换到ORACLE上，已解决迫在眉睫的风险问题，给予我们后期微服务的建设留有建设时间。

而在服务化的建设上，我们选用了DUBBO，DUBBO是阿里开发的一个分布式服务框架，用于提供高性能和透明化的RPC远程服务调用方案。在使用这套框架的时候，我们公司CTO冯总之前在支付宝担任高管多年，拥有相当广泛的资源，随机为我们开发人员拉了一个和阿里开发人员的一个QQ群，使我们在DUBBO服务的建设上得以快速的推进。除了以上两大块，我们还进行了CDN的接入，升级硬负载等等。

在ORACLE整库切换的过程中，无疑也是个大工程,倒是搭进去的人数到还好,二哥,老杜几个人牵头,大部队还是顾业务,向前冲,库切完后,确实又清静了,坚持到现在快两年了,切换之前几乎优化工作量全铺在了sql上,可见ORACLE确实也不是吹出来的。而在服务化治理方面，我们主要是解决平时如下这些问题：
       1. 打包构建时有严格的顺序,常常出现一句话:”不对,必须先打资金包,在打网站包”,甚至还出现过发布上线出错现象,且对于不太熟悉的员工对于顺序基本没概念。
       2. 耦合过紧,缺少机动性,违背敏捷原则,常常一个改动全部打包,整站发布。
       3. 所有功能运行在同一篮子中,一损俱损,如上述提到的网盟,当时调用一个第三方链接,虽然开新的线程处理,但是跑一会就整个tomcat无响应,发现对方服务不可用,等超时,结果自身线程爆了。
        4. 业务交叉,管理混乱,相互之间直接数据库表查询,业务变更后引发连环问题。
       在这种背景，我们推动了服务化治理,当时由架构的老杜负责,选择了阿里的dubbo,并且对原来规划的几个大块(资金,财务,风控,网站...)之间的依赖进行服务化拆分,这个拆分难度也可想而知,尤其当时重心在保业务这个问题上很是为难。

虽然最终完成的不是太完美,甚至还出现了一些性能问题，但是通过服务化，我们解决了更多棘手的问题。

2016年7月，老白正式提出微服务4.0建设的目标。而微服务在当时冒出了一些相关的文章，但是案例并不鲜见。包括我们也去听了一些微服务相关的讲座沙龙等等。但当我们在讲座上提问后，发现对方其实也还是在摸索阶段，手上也并没有相关的成功案例，而我们把平时所遇到的问题提出时，对方也是模棱两可，我们也未能获取到一些较好的方案。于是在后面的微服务规划及开发的过程中，对于网上的文章，也就是让自己的思维发散点，最终还是需要在当我们自己遇到问题时，去琢磨，去思考，去探索。

而我们这次为何要改造成微服务，主要是以下2个痛点：

1. 团队越来越庞大，就网站这一块，由原来几人已经发展到接近50人，可以想象这50人日常开发对于堆砌的功能如何之多，所以大部队行动起来也就没法日行千里了。

2. 服务化3.0还是不够彻底，大模块之间耦合虽然已经解开，但各个大模块内部还是一锅粥。

在拆分规则上，自然跟业务领域要联系紧密。原则上，就是将相对比较独立的，且从前端到后端由专门的队伍全权负责,包括数据库都独立出来。(而核心业务还在ORACLE,其他业务切到了postgresql),这样无形中也强制责任明确了,小队伍专心投入,将各自服务做精。但这当然也在无形中带来些麻烦,如增加管理,运维,沟通,维护的成本,同时在对于事务的处理上也增加了难度,需加强内部公共约束,提高队伍素质,保证服务稳定及自动化建设,以及通过补偿及两阶段提交等方式折中解决分布式事务,尽量走最终一致性。而在数据库层面进行了垂直扩展后，至少短期内解决了数据库单兵作战的问题,性能方面提升的同时能做到真正的故障隔离。

如在运营系统内部，我们根据业务特性进行了拆分。拆成以下几大块： 1. 会员中心 2. 活动中心 3. 微信平台 4. 优惠券中心 5. 离线平台 6. 合作中心 7. 开放平台 8. CMS系统

至此，会员4.0系统的上线，代表着运营研发这边，整体的微服务已经雏形出来，后面还剩余了对前端包的拆分及业务监控的建立。