微信号:ali_tech

介绍:阿里巴巴官方技术号,关于阿里的技术创新均将呈现于此

你写的代码,是别人的噩梦吗?

2017-12-15 08:07 Frank

阿里妹导读:Frank,是来自阿里国际技术事业部的高级技术专家,从业十年,也是一位英语说到飞起的型男。今天他将与大家聊聊关于企业应用架构实践的话题。

阿里高级技术专家Frank


从业这么多年,接触过银行的应用,Apple的应用,eBay的应用和现在阿里的应用,虽然分属于不同的公司,使用了不同的架构,但有一个共同点就是都很复杂。导致复杂性的原因有很多,如果从架构的层面看,主要有两点,一个是架构设计过于复杂,层次太多能把人绕晕。另一个是根本就没架构,ServiceImpl作为上帝类包揽一切,一杆捅到DAO(就简单场景而言,这种Transaction Script也还凑合,至少实现上手都快),这种人为的复杂性导致系统越来越臃肿,越来越难维护,酱缸的老代码发出一阵阵恶臭,新来的同学,往往要捂着鼻子抠几天甚至几个月,才能理清系统和业务脉络,然后又一头扎进各种bug fix,业务修补的恶性循环中,暗无天日!



CRM作为阿里最老的应用系统,自然也逃不过这样的宿命。不甘如此的我们开始反思到底是什么造成了系统复杂性?我们到底能不能通过架构来治理这种复杂性?基于这个出发点,我们团队开始了一段非常有意义的架构重构之旅(Redefine theArch),期间我们参考了SalesForce,TMF2.0,汇金和盒马的架构,从他们那里汲取了很多有价值的输入,再结合我们自己的思考最终形成了我们自己现在的基于扩展点+元数据+CQRS+DDD的应用架构。该架构的特点是可扩展性好,很好的贯彻了OO思想,有一套完整的规范标准,并采用了CQRS和领域建模技术,在很大程度上可以降低应用的复杂度。本文主要阐述了我们的思考过程和架构实现,希望能对在路上的你有所帮助。


复杂性来自哪里?


经过我们分析、讨论,发现造成现在系统异常复杂的罪魁祸首主要来自以下四个方面: 


可扩展性差 


对于只有一个业务的简单场景,并不需要扩展,问题也不突出,这也是为什么这个点经常被忽略的原因,因为我们大部分的系统都是从单一业务开始的。但是随着支持的业务越来越多,代码里面开始出现大量的if-else逻辑,这个时候代码开始有坏味道,没闻到的同学就这么继续往上堆,闻到的同学会重构一下,但因为系统没有统一的可扩展架构,重构的技法也各不相同,这种代码的不一致性也是一种理解上的复杂度。久而久之,系统就变得复杂难维护。


像我们CRM应用,有N个业务方,每个业务方又有N个租户,如果都要用if-else判断业务差异,那简直就是惨绝人寰。其实这种扩展点(ExtensionPoint),或者叫插件(Plug-in)的设计在架构设计中是非常普遍的。比较成功的案例有eclipse的plug-in机制,集团的TMF2.0架构。还有一个扩展性需求就是字段扩展,这一点对SaaS应用尤为重要,因为有很多客户定制化需求,但是我们很多系统也没有统一的字段扩展方案。