BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

邓光耕:架构演进是一门平衡的艺术
录制于:

| 受访者 邓光耕 关注 0 他的粉丝 作者 InfoQ 关注 9 他的粉丝 发布于 2018年5月17日 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。
12:07

个人简介 邓光耕,来自付钱拉,目前在付钱拉担任高级技术经理。

QCon是由InfoQ主办的全球顶级技术盛会,每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来,已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 请简单介绍一下您自己。

邓光耕:我来自付钱拉,目前在付钱拉担任高级技术经理,之前是在一个第三方支付公司呆过大概三年多的时间,然后就到了付钱拉这里。

   

2. 借鉴付钱拉系统架构的演进,您觉得架构的演进大致可以抽象为哪几个大的阶段,在每一个阶段可能会重点面向什么问题,有哪些挑战?

邓光耕:我觉得大概可以分为三个阶段。

第一个阶段是系统的筹建期,第二个阶段就是系统已经成型,去响应需求,第三个阶段就是可能在业务已经相对比较固定的时候,需要去做一些性能方面的优化,大概是分为这三个阶段。

第一个阶段其实就是要快速的去把系统做出来,这个时候不需要去过多的纠结于设计是不是合理、方案是不是好,当然,假如说开发者的时间很多,人力又充足,这些情况可能要排除在外。

第二个阶段,系统已经做出来了,现在已经开始跑业务了,但是,这个时候其实重点是要保障系统的稳定性,可能要做更多的测试,然后去发现系统里面的Bug,保证系统执行的结果正确。

第三个阶段,业务相对已经比较固定了,这时候交易量会比较大,系统一定会面临一些性能方面的问题,这个时候想办法去怎么解决性能的瓶颈。说到每个阶段的挑战,我觉得其实每个阶段挑战都是一样的,就是要抓住每个阶段的重点是什么,因为如果你的重点抓错了,你的方向就搞错了。

   

3. 付钱拉作为一个金融云开放平台,对高可用性和安全性都有很高的要求,为此付钱拉在架构层面都做了哪些工作?

邓光耕:我说一个具体的点,比如说我们选择了消息队列做这种服务之间的通讯,为什么选择消息队列而不是选择这种RPC的方式,因为消息对列有一个暂存消息的作用,消息在队列里面它不会丢失。假如说这个队列的消费者服务,因为一些问题服务挂掉了,如果这个服务事先做好了一个多点部署的方案,那还有另外一个服务去可以消费这条消息,我觉得这个点就是可用性的应用。

另外我们也做了灰度发布,通过灰度发布可以保证每次做功能上线的时候,不会影响线上的交易,交易不会中断,这也是很大程度上提高可用性。

再从架构层面说说安全性,我们还拿这个MQ来说,MQ在发送消息的时候,比如说有一个服务去订阅了这个消息,这时候消息队列不会把这个消息清掉,我要等到服务给我一个应答,也就是ACK。服务给我一个ACK之后,这个消息才会清掉,如果不给我ACK,这个消息我就会一直放在这,别人也拿不走,所以说这个点也能够用于比如可以避免一些重复支付,导致资金风险,这就是我理解的安全性。

   

4. 每次演进都意味着改变一些以前固有的做法,在改进的过程当中势必会面临一些阻力和风险,面对这些阻力和风险你们是如何处理的?

邓光耕:我觉得其实每一次演进都会有这种阻力和风险,这个几乎是没办法避免的,风险有时候会大,有时候会小,我们其实就是坚持一个适用与实用的原则,让所有对架构的调整,或者改动都要在这个大前提下去进行,这样风险的范围就是一个适度的范围。

   

5. 架构获取是一门平衡的艺术,在这个演进的过程当中,你们有没有做过一些妥协?比如说在这个演进的过程当中有没有哪些坑是可以提前避免掉的?

邓光耕:我的理解是:一套架构它首先它不是凭空产生的,不是凭空造出来的,这个架构一定是根植于具体的业务场景,或者是业务模型之上的,既然架构是依附在这个业务上面,那必然会随着业务的调整去做一些调整。同时,业务发展或者是业务模式又跟比如说产品的市场定位,还有公司的战略发展方向都是有密切的关系的,所以说当这些因素累加在一起的时候,在做一个架构的设计的时候必然需要去考虑一些妥协。另外,我觉得要去平衡,就要考虑妥协,我觉得平衡本身这个词它就有些妥协的含义在里面。

至于怎么提前避免踩坑?首先一点,就是在一开始设计的时候要去做一些详细的设计和思考,不断的去推演,避免这种会导致后面反工的事情发生;另外一个方面,要对一些架构的细节去不断的做一些打磨,尤其是那些关乎于架构的稳定性,或者是建设性这些细节,一定要不断的去想一些丰富一些场景去验证它;还有一个,我认为是过渡设计,开发者要学会去评估,比如说有的设计,我现在不做,是不是可以放在以后做也能做,有的设计我是不是现在不做的,以后做起来就比较费事,所以这一点就是比较靠经验。

   

6. 您刚才也说,在架构的选择当中可能是会依附于业务的需求,那在做架构选型的时候,应该着重考虑哪些方面?

邓光耕:首先要看有多少人力、有多少时间,以及要把这个架构做到一个什么程度,这个要先想清楚,就是时间成本和质量的问题;另外,开发者要清楚,自己的业务特点是什么、业务特性是什么,拿付钱拉来说,它是一个金融相关的系统,安全稳定这就是它的特点,每一次这种交互都很重要,尤其是一些支付的场景,只能做一次,不能多做,不能少做,这是它的特点。要清楚自己的特点。

还有就是,架构要适用于一个什么样的场景,比如说到时候要支撑一个多大的交易量,或者这个架构出来以后需要多少硬件资源去支撑,这就是场景这方面。另外还有一点就是要面临的具体问题,这个也特别重要,一定要知道自己的架构是为了解决什么问题,这样才能保证方向不会错。

   

7. 能否简单谈谈你们是如何协调管理、开发、测试、运维等各类角色,完成架构演进的?

邓光耕:其实我们团队在这方面还真是没有花特别大的精力在协调沟通上面。因为我们在招人的时候,就有几个基本的准则,要踏实肯干,有责任心,我们这个团队大部分都是这样的一个人组成的,整体的执行力就比较强。另外呢,有些事情是测试是牵头的,有些事情是运维牵头的,有些事情可能是开发牵头的,时间久了大家就习惯于这种团队的配合,或者是说形成了一种默契度,也可以说是形成了一种做事的风格。所以说当项目组出现一些事情,需要其他支援的时候,大家就是该给支援就给支援,因为大家都觉得这个事情就是自己的事情。

   

8. 您能否为从事架构设计的听众分享一些其他建议?

邓光耕:我有几个建议:一个是架构是根植于业务之上的,架构可以复杂,可以简单,有些时候该有,有些时候也可以没有,这些都是要视业务发展来定的,要看系统的复杂程度。另外一点,人要驾驭技术,不要被技术驾驭,也就是说当你在面临一个具体问题的时候,要去用好你的技术,选择那个最直接有效的方案去解决你的问题,而不是说去搞一些技术秀。还有一点,其实没有一套方案是完美的方案,可以解决所有的问题,或者达成所有的目标,所以在做选择的时候,在选择要得到某些方面的收益的时候,就应该去接受其他一些方面的损失,这是很自然的一个现象,你要做得就是让收益最大化,这就是我这次来主要想跟大家去分享和交流的一些想法。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT