欢迎来到Doc100.Net免费学习资源知识分享平台!
您的位置:首页 > 程序异常 >

架构师之道:怎么架构、设计与实现高质量的远程接口

更新时间: 2014-01-05 02:57:06 责任编辑: Author_N1

 

架构师之道:如何架构、设计与实现高质量的远程接口
一、【前言】
   刚刚经历完一个公司的项目,涉及很多架构设计、远程接口。在使用(我们自身)平台设计的接口过程中十分曲折、全体痛苦,而我负责的传真接口却让外部客户(电信方)与内部客户(应用方)感觉愉快清晰而受内外好评。
  因此,我感觉颇有必要将我历来的设计经验分享出来,以帮助团队成长,未来的项目中少走弯路,作出成熟的、高质量的接口设计。

二、【正确的人,做正确的事】
任何优秀的架构师都明白的道理:
1、需求永远是第一位的,接口为需求服务。需求是接口的“衣食父母”。

2、应用方(工程师们)也是另一种意义上的"衣食父母",如接口架构不良、实现较差,难用难扩展甚至没人愿意用,则最终会被“父母”抛弃。

3、有时候,我们看似比“衣食父母”更专业、更有经验,但并不见得比“父母”更有“生活智慧”,不要去试图教训“父母”,或让“父母”适应你。相反,尽一切可能适应或满足“衣食父母”的需求才是正确的设计之道。

4、好酒也怕巷子深;好设计需要好的媒介加以表达。写一份优良的接口设计文档,并在评审中清晰明白的阐述设计思路,是架构师的基本功。

5、好酒是与好窖、好水、好温度、好酿酒师密不可分的(再加上一段时间)。让团队成员尽可能广泛参与设计与评审,才能集思广益、查漏补缺,更能沟通顺畅、执行无误,切忌孤芳自赏、闭门造车、欲速不达。

6、如果你的团队中的“木桶效应”非常明显。你需要做两件重要的事:不要让自己的工作成为短板;尽可能补救那块最短的板。

三、【人与制度】
人与制度的关系,就像人与自然的关系。人能改变自然,但首先是被自然改变。
优秀的设计背后一定有优秀的作者,但如果“自然环境”不良,好设计也难以诞生或容易夭折。
如果你的团队一直不能诞生优良的设计,最大的可能只有两点:人或自然环境相当不佳。

具体到影响设计质量的制度建设上,我只建议4点:
1、让你团队的最优秀者作独立设计师或主设计师,无论是产品设计还是架构设计。
2、需求评审必须严格且广泛参与,业务流程图(注意:不是PageFlow)与业务规则描述是产出物中的必备内容,可多轮直至全部细节都经过评审
3、架构与接口设计的评审也必须同样不可省略,可多轮直至满足全部需求点(含潜在需求)方可通过评审
4、接口的设计与现实最好由同一人负责,别推脱或假手他人,甚至让新人或实习生来开发接口的实现

四、【接口的协议与框架】
目前,最常见的远程接口协议是基于HTTP协议基础上的soap、hessian、Json-RPC等。前两者,我应用已久,我对技术人员的协议建议是:hessian。

关于常见远程协议的比较,可参看JavaEye上的一篇文章:http://dalezhu.javaeye.com/blog/190962

对于Java开发者来说,支持soap(webservice)协议的最好的框架类库是xfire(另一个是axis远不如xfire好用);而支持hessian协议的框架类库,最好的就是spring。因此,hessian+spring是我的推荐,也是很多架构师的不二选择。

五、【远程接口的架构设计】
比起协议与框架的选择来说,接口的架构设计才是体现设计师真正水准的分水岭。

一般来说,无论远程接口还是本地接口,常常会有异步执行的情况:即调用方call被调用方的接口,同步返回请求成功,但实际操作是被调用方延后去执行的。这种时候,提供回调接口是最佳选择,只有万不得已之时,才考虑让调用方轮询被调用方的接口,以查询执行结果。

因此,回调模式与轮询模式相比,无论是及时性、安全性、可靠性以及性能效率上远胜不止一筹。只有一种极特殊的情况下,我们完全无法采取回调模式:即被调用方的系统过于老旧,不可改造,无法回调不同的调用方。大多数时候,我们都可以用回调模式取代轮询模式,甚至可进一步做得更完美一点,让被调用方对于调用方不存在直接依赖(答案我不直接讲出来,自己思考一下怎么将<直接依赖>变成<优雅且万能的间接依赖>)

架构方案也是综合技术能力的体现,需要设计者在协议规范、语言能力、面向对象思想、数据结构、设计模式等方面不能存在明显短板。记住:一份出色的设计文档是你设计工作的最终载体。

六、【远程接口的设计实现】
我列举一些易犯(特别是接口设计的新手)的常见问题:
1.不定义接口类(interface),而是直接定义抽象类。

2.接口返回对象参差不齐,随便定义。
——最好定义全局统一的Result对象:resultCode(全局返回码), resultObject。

3.异常处理非常不统一,有时候用CheckedException,有些时候用UncheckedException,有些时候用ErrorCode。
——我的建议是所有异常在方法内部捕获,统一在ResultCode(全局返回码)中定义一段错误码,通过输出结果返回。

4.使用Map作接口方法的输入、输出,还美其名曰:简单灵活。有时候甚至只有一个Map作输入。
——Map非常不适合作公共API方法的输入输出(仅非常特殊时除外),直接导致弱类型问题、易引发潜在BUG且调试困难、不容易书写数据对象的(反射式)校验代码。另外,有些人反映hessian协议下存在Map中的自定义对象的序列化问题,其实很简单:1、不要使用Map;2、覆盖一下这些对象的hashCode方法。
好的接口方法的输入、输出无不定义为强类型,且应分别输入多个不同的业务数据对象(易于校验、维护与测试)。

5.接口包不提供输入对象的校验,对象长度、格式等只在文档中说明。
——建议接口包统一提供输入对象的校验:是否必填、长度与格式。最好定义一个Validatable接口:含validate方法,同时让所有输入对象实现之。

6.远程数据对象未实现序列化接口。

7.未考虑远程接口的安全性问题。
——有两种方案可让远程接口提升安全性:一、使用HTTPS协议;二、接口方法上增加一个安全码参数作安全检查(方法一:调用方与被调方用同一密钥对时间戳作DES加解密以便比对)。前者属于协议层安全,后者属于应用层安全,两者也可以同时提供,我建议仅用后者即可。

8.不作单元测试。
——关键类的public方法最好先作单元测试。另外,如完成一个接口方法的实现类,最好书写单元测试代码自测之(事半功倍之举)

还有很多细节问题,需要你自己的分析、判断与经验。这里请牢记一句话:细节决定成败!
当你完成一个接口类库包,就可以打上版本发布(建议与接口文档同时发布,且版本保持一致)。如以后升级类库,记住先升级文档。

七、【后记】
到此,我已经比较全面的介绍了接口设计主要原则与重点,但仅靠别人的分享与培训是不足以成为一位出色的设计师的。

多阅读优秀的设计文档与接口源代码,多学习与领悟更有经验者的分享,多思考why that/how better,多关注接口使用者的需求与感受等等诸如此类,长此以往、严格要求自己才是出色成长的必由之路。
上一篇:上一篇
下一篇:下一篇

 

随机推荐程序问答结果

 

 

如对文章有任何疑问请提交到问题反馈,或者您对内容不满意,请您反馈给我们DOC100.NET论坛发贴求解。
DOC100.NET资源网,机器学习分类整理更新日期::2014-01-05 02:57:06
如需转载,请注明文章出处和来源网址:http://www.doc100.net/bugs/t/16570/
本文WWW.DOC100.NET DOC100.NET版权所有。