(冯忠旗，付钱拉高级技术经理，曾经是IBM中国开发中心IaaS私有云技术负责人。2014年加入付钱拉，主导付钱拉技术平台的研发和负责平台相关的实时预警系统、报表系统、电商服务解决方案和理财服务解决方案等。个人比较关注高并发、高可用的架构设计，对分布式系统建设过程中的业务拆分、分库分表、消息队列、性能调优等方面有深入研究和实践经验，有团队管理经验，热衷于技术研究和分享。)
QCon2017全球软件开发大会上，付钱拉高级技术经理冯忠旗老师分享了付钱拉针对金融云行业的痛点，以及付钱拉系统架构的设计和实战经验，并且介绍了他们在改进用户使用体验方面采取的一些措施及他们在使用开源项目方面的一些经验，分享内容备受推崇。
会议结束后，冯忠旗老师在接受InfoQ视频采访时，详细介绍了付钱拉技术团队如何架构系统工程以及付钱拉技术栈如何从基础设施到应用，以及《付钱拉开发者规范手册》诞生的始末等，以下为整理的视频采访的部分内容：
03:04
你加入付钱拉也3年了，您认为金融云的行业痛点有哪些?
冯忠旗：这个问题也是我的痛点吧，我觉得做金融相关的最大的痛点是要关注用户，了解用户，你是在帮助用户解决问题不是在做系统。金融相关用户最大的痛点是什么?第一个我觉得是安全，如果把不同的系统划分安全等级，安全要求最高的是飞机的驾驶系统，或者航空之类的，因为它和人的生命安全有关系，系统出现一个小小的BUG，损失非常大，有生命危险。其次就是金融，因为它和钱有关系，对金钱的关注和损失每个人都很在乎，所以对金融的安全要求即钱的安全要求是非常高的，金融系统用户对安全问题是零容忍。举个例子，用户上一家网站购物并且浏览信息，这个网站页面突然报404了，或者页面崩溃了，你刷一下能出来，这是能容忍的，并且用户觉得还行，因为没有造成太大的损失，最多觉得可能这个系统做的不是太好，不是做技术的人更不会关注这个系统技术做的好不好。试想你用银行卡发起一笔支付，然后银行短信告诉你扣款成功了，但是系统告诉你支付失败重新支付，用户这时候是不能容忍的，也就是所谓零容忍。类似这种都是和用户相关的痛点，我关注的是用户，用户的痛点也是我们的痛点。
05:26
那么通过你们的知识如何架构这个系统工程?
冯忠旗：这是一个系统性的工程，用户在支付过程中发生资金损失原因可能是复杂的，像资金安全保障它是一个系统全链路需要关注的事情，从最底层到最顶层都要去做、去优化的一件事情。从一开始通信层面最基本的要求是全站https，内容传输层面我们有自己的加密机，接入安全的SHA1、RSA、MD5等私钥公钥都会保证报文的签名和加密。到了我们的系统，用户的数据是敏感的，不能明文展示，包括我们自己的人员从数据库层面和运营层面都看不到用户的数据，这是必要的也是必须的。再往下应用层面，举个场景，如何造成资金损失，支付的多付少付等等这样的资金风险，写程序的人可能知道最大的问题是由程序并发所导致的资金重复处理，这就造成损失了，这个问题也要做一些事情，这是最常见的。据我了解做支付的公司，多多少少都发生过类似的事情，如果系统是从0到1然后再到优这样的过程的话，一定发生过类似的资金风险，这样的数额还不小，我们也发生过类似这样的问题，但是我们很快通过技术手段就解决掉了，并且这也是我们最宝贵的经验和教训。再往下到底层，比如应用服务器不能公网访问，通过代理或者其他的方式，确保服务器的访问安全。再拓展一下，分布式环境的节点是多个，要保证部署是隔离的，要保证两套环境或者三套环境的物理主机处在不同区域，如果一台节点挂了，另外一台是相互影响的，还有很多很多。总之，要做好安全的事情，这是一个体系的问题，每个层面都有要考虑的东西。付钱拉根据目前400万到500万的规模，我们做了很多的尝试。这个问题再上升一个高度就是可用性，付钱拉的交易量在互联网行业不是最多的，这个是受限于付钱拉的规模，但是付钱拉首先我们是金融系统，金融系统最重要的是部署一套可靠的、稳定的解决方案，而不是要牺牲一些点追求新鲜的东西，这是我们一直追求的理念，用过我们系统的人，包括我的演讲过程都是在阐述这样的观念即“金融系统的可用性”。
09:35
付钱拉现在主要的技术栈是从基础设施然后到应用，包括devOps，谈一下技术栈?
冯忠旗：我们有用一些开源的组件，但是多数是我们自己实现的，我们技术团队比较庞大，能力比较强，也有很多分享都是关于一些解决问题的。像devOps这一块，我们的测试和运维团队，基于jenkins等框架搭建的devOps框架，实现了全部是自动化、无人值守的去发现、解决问题。像分布式和微服务这一块，我们也尝试过一些框架，包括dubbo，ZK，还有国外的很多框架都研究、尝试过，但是最后我们还是自己实现了一个框架，这个框架正在准备做一些开源的尝试。这一块我们基于微服务的基本要素，比如服务的注册与发现、熔断机制、监控机制、路由、限流、防刷都考虑进去了，并且基于我们的业务场景加了一些功能，比如服务编排，其实好多系统不怎么关注服务的编排，微服务之间调用是无序的，但是对于我们金融系统，有些业务是有序的，比如我们固定是A到B再到C节点，是有限的状态，所以我们把这一块也加进去，还有多协议的支持和异构性的支持。刚开始我们这个框架只单纯支持RabbitMQ，慢慢加入了redis等。微服务不是什么新东西，最早是SOA，只是把这个东西做的更适应目前的业务架构或者说市场，解决SOA之前没有的东西，提出这些理念和要点之后，有很多的框架很多公司自己去实现落地。像我们对spring cloud的研究，cloud在国内没有那么大的规模，在国外比较多一些，因为它相对比较庞大一些，对异步这块我觉得实践场景支持不是太好。Dubbo是RPC调用，后面的版本也做了一些调整来支持REST API。HTTP REST API带来的问题是什么，服务的划分往往是比较宽的界限，服务一定是由很多业务功能组成的，相对比较大，但是高可用场景下，一个服务可以再拆分细到一定级别，比如线程级别，那么对于服务内部的高可用该怎么支持呢?用http rest同步调用怎么处理阻塞，有了大问题只能说把整个节点摘掉或者换掉，服务节点内部没有办法实现。至于阻塞，所有的系统交互性能最大的瓶颈就是阻塞，CPU也阻塞，CPU线程切花就是释放出空闲的线程来处理其他工作。当你去餐馆吃饭点餐的时候不用什么事都不干只是等着，你可以看看手机，干干别的事，这就是一种异步，我可以做别的事情，当有菜上来再吃。我们系统更关注的是服务内部模块之间如何实现高性能，那就是多数同步转异步，分布加异步能充分发挥并发的优势出来，否则发挥不出来，所以我们的框架，这一层做的是比较好的。
15:18
有没有考虑过像kubernetes这样一些最新的技术?
冯忠旗：我们技术团队是比较开放的团队，也在尝试和了解其他做的最好的，但是要用的话，一定是要经过我们切实的测试或者验证后才会用，所以当前的框架还是我们自己研发的框架，但我们不是闭门造车，付钱拉最好的特点就是开放的思维，从产品到运维，再到整个策略都是开放的，包括参加QCon等活动去了解大家是怎么做的，一种学习的心态，用我们CEO的话来说就是空杯心态，自己永远是一个杯子，杯子的水永远是不满的，需要走出去了解别人是怎么做的，好的东西尝试看能不能融入到我们系统中来。
16:25
看你之前的分享，付钱拉有两个外挂系统，一个日志归集系统，另一个是实时预警系统，
一般企业的监控预警系统会选择外挂的方式，日志作为生产系统的重要组成，为何也采用外挂的方式?
冯忠旗：我们对外挂的理解是外挂非业务核心，核心是交易系统，所有支持交易服务的外围系统都要用外挂来实现，比如监控的动作，因为异常挂掉或者不能提供监控的话，不能影响当前的交易。同样日志系统我们用外挂，日志系统最大的痛点是哪里，比如每天有400万到500万笔的订单量，一笔订单流转7到10个模块，如果一个模块打一个点，记录1到2条日志，那么一笔订单就对应十几条二十条的日志记录，一天400万到500万笔订单，那么日志量就是1000多万以上。我们刚开始实现的最初的版本，用的传统的办法就是记录到数据库，每天这么大量的增长，当系统到一定程度的时候，你会发现相对来说，数据库IO就成为一个瓶颈，因为数据库存储没有那么快，所以这时候我们把它定为外挂，不管日志怎么打印，怎么输出，怎么监控，不能影响交易系统，所以我们把日志打的跟二维表的形式一模一样，关系数据库的二维表怎么展示我们日志就打成什么样，打印出来之后，实时收集分布式环境不同的日志文件，收集之后通过自己开发的程序实时解析，之后展示在可视化界面上来。通过这个方式来避免数据库之间的交互，再一个就是打印失败或者成功也好，展示成功也好失败也好都不影响交易。日志是重要，但要看和什么比，和交易系统比就只能认为它是可外挂的。
19:23
前段时间看到您这边有一个开发者的规范手册，我们看到阿里、谷歌也有类似的手册，能谈谈这份手册的诞生的过程吗?
冯忠旗：这个手册是我一手撰写的。我在付钱拉2年多到3年的时间，金融系统都是我一手像孩子一样照顾过来的，经历好几个系统都是这样，所以系统里面任何的问题，任何的经验我都非常的清楚。刚开始在我们第一套系统的时候，可以说是先趟坑、先实践的一个过程，总结很多方法论、经验和教训。有幸参加第二个系统的设计和搭建的时候，就把这一套知识和理论平移、横向扩展，但是你会发现用的过程中没那么容易，不太可能很顺畅、很容易的把它应用上去，我就经历过这样一番过程，经历完了之后就发现原来有方法论到底怎么用还是很大的事情。在应用成功之后我在想，第二套应用成功了为什么不把这些东西拿出来跟大家分享一下?所以我就开始总结去写这些东西，时间点非常凑巧，我当时刚写完了没发布，也没有看到阿里的，我同事就看到阿里分享这个东西，正好赶巧了，我就学习了一下阿里的，我们一直抱着很开放的心态，毕竟每家都有长处，像阿里这样的公司肯定有很多学习的要点，就和大家一起过了一下阿里的开发者手册，我们发现有种惺惺相惜的感觉，别人家遇到的问题，你家也遇到了，好多它里面提到的要点跟我们是相似的，比如他提到的，开发人员要执行sql，一定是要先看执行计划，执行计划里有一个type，type是all的话是不行的;还有并发下多写的问题，通过数据库乐观锁可以去解决，避免并发下资金重复支付就是通过这个方式解决的，包括提到跟我的意见很一致的，不要轻易注解transaction，好多人是习惯就加上了，但是加上带来的问题就是第一有性能损耗，第二如果代码写的不够好或者不小心某些东西写进去了，比如多个操作，那么并发的情况下就有可能发生数据库死锁，一锁二，二锁一这样相互交叉死锁，所以要慎用。好多理念一样，我们对自己的技术更加有信心了，大公司遇到的问题我们也遇到了，所以我就把这个东西总结了一下写成规范，包括基本操作的、性能的、还有安全的等，这些东西都是我们通过平时的经验总结出来的，这就是当时出这个手册的契机。
23:56
第三方调用付钱拉的产品和服务有两种途径：API接入、SDK接入，很多To B的企业包括像AWS都采用这两种方式，在我接触到的案例中，这两种方式都有问题。以国内云厂商为例，大多数API文档写的不好、不全甚至压根就没有，你们采取了哪些措施改进用户的使用体验?
冯忠旗：因为我们是面向C端和B端都有的，所以我们的API的形式就多样化，有纯rest API、web service、h5 SDK等等。你说的这个问题非常好，API多、乱，怎么去解决这个问题，我们系统的API设计这一块要求只有一个：不懂技术的人能看得懂就可以了。API一定要让接入方用起来非常的简单，如果你在API的接入过程中这个不懂要打技术电话，那个要qq沟通，那么这个API就失败了。我们的API是核心技术人员审核，审核完以后非技术人员评价它是否好使。也有API做的好的，像我看到阿里、腾讯开放平台是相对做的比较好的，但最好的还是AWS，因为我之前在IBM工作的时候AWS也是做IaaS的，我的同事对AWS熟悉一些，最早的rest API是AWS做的最好，据说是从零几年开始做这个平台的时候，他们其中一个目标就是要去做多少标准的API，一是可用，二是有多少的量级，API本身也是一种拆分的思想，他们一开始设计这个系统的时候就认为API是一个很大的部分，刚开始IaaS发展很好的时候，一个企业提供的服务能力，提供多少API成为了一个指标，几千个，几百个，所以这个东西还得重视它。虽然国内可能比较多，或者乱一点，大家也许为了迭代快速周期，但这个一定要重视，用我的话说就是傻瓜都得看得懂。
27:05
谈谈SDK的版本更新问题。一些新的功能、特性和改进怎么及时送达到用户的产品中?“秒收SDK”是付钱拉的主打产品，在对旧版SDK的兼容性方面，你们是怎么做的?
冯忠旗：这个有两个点，第一个秒收讲的是用户接入简单快的问题，官网上可以看到，我们7行代码，快速接入。另外一个是兼容性，我们目前的SDK的兼容，第一个就是要做好向下兼容，我们上一个版本一定会考虑之前接入的商户和用户，其实也可以不做兼容的，因为好多的开源软件，1.0、2.0就是两回事，1.0也维护，2.0也是维护的，这也是一种方案，像我们常用的开源jar包，1.0也有，2.0也有，有兼容的也有不兼容的。但是我们做金融系统，每一次的功能上线都会考虑向下兼容的问题，但这带来了系统所谓的复杂性，但是我们认为如果不能满足用户的这一块，这块是可以忽略的。我觉得还是以用户为主，以用户和业务角度去考虑技术层面的东西，如果你的东西再好再简单，用的人不舒服也是不对的。
28:51
最后一个问题是和开源相关的，您知道现在开源是很主流的，在技术栈中占很大的比例，您是怎么处理跟上游项目的关系，然后你的成本是怎么考量?
冯忠旗：是指说和开源社区吗?
29:35
和上游的社区如何做到平衡，比如说RabbitMQ，有很多你可能需要的feature，可能过两天2.0发，但是你基于上一个版本做的开发，如何来平衡的?
冯忠旗：这个东西还是有两个思路，第一如果这家公司是以技术驱动的，你想做大做强，那么开源只能作为参考和依赖，如果完全依赖开源的东西去构建自己的核心技术和核心业务系统，并且想长久发展，我觉得这可能是有一些风险的，就像你说的开源社区会有不停的迭代并且有自己的维护性，比如说一个开源的东西刚开始挺好的，社区的活跃度和维护度，包括版本更新很快，但是经过一个阶段以后，你发现这个产品生命周期到了后期，所以维护就下来了活跃度也上不去，这时候对你技术团队，对你公司打击性非常大，所以技术也好，CTO也好，就牵涉到技术选型的问题，技术选型的时候一定得考虑这个点，像之前做IaaS层的时候我们团队也有很多出去创业做IaaS服务创业项目的，有基于开源的，还有自己做的，大多数是基于开源的，但是你发现在市场上能存活下来的，技术一定是自己挖掘自己去实现的。我们会考虑社区活跃度，会尽量的设计实现脱离容器、脱离框架底层的东西，微服务也讲脱离容器，所以这块我们自己的核心框架，就是刚才我提到准备开源的框架也都是这样设计和考虑的。另外一方面如果我们已经用了某些东西，比如RabbitMQ，redis，这块的升级与选择还是以业务为导向的，以用户的场景为导向，假如当前架构能够满足日交易量千万，版本运行非常稳定，从业务层面我们不会升级，除非遇到一些问题，比如说开源组件的BUG升级改造，我们会考虑，但是那个过程我们会经过各方面评估压测再去用。我们也会应用外围的东西，但是真正核心的东西还是自己去实现，尽量从技术选型，一个是从业务场景考虑，另外是考虑长期的发展。
33:08
我能不能这么理解就是说我们对于开源主要还是使用，反馈的比较少?
冯忠旗：我们目前用到的东西不多，反馈比较少。
33:29
上游的东西基本上满足我们的需求。
冯忠旗：对，我们选的东西都很成熟，非常的成熟了。你提到的不知道是不是这个意思，开源社区的东西我们是拥抱的心态，我们正准备把我们的框架做一些开源。因为我们和别的竞争者也一样非常喜欢开源，只有开源了竞争了才能往前发展，闭门造车肯定是有问题的。
34:08
谢谢您。
A5创业网 版权所有
