一个不好的软件设计案例

最近，在一个项目的开发过程中，遇到这样一个问题。

在整个系统中，存在有业务交互的两个服务：'A'和'B'，由于两者之间使用的应用层协议不同，

所以中间需要一个‘proxy’服务负责进行报文的协议转换。

A <—> proxy <—> B

但是，由于A->proxy有些字段的类型和proxy->B的字段类型不同，导致B最终收到的报文内容错误。

该项目的技术负责人提出的解决方案是，proxy对收到的A的报文中的特定字段（按名称查找）根据B的接口规范进行类型转换后再发给B。

但是这种解决方案却引入了两个潜在的问题：

1、最直观的的一个问题是，经过proxy的报文的每个字段，如果与那些特定字段的名称相同，则都会经过类型的转换——不论这个报文的字段是否需要转换。要避免这样的问题，新的报文则不能使用与已有报文的特定字段相同的字段名称，这显然给后续新增接口的设计带来了不便。

2、proxy本身的定位是一个协议转换服务，从服务的独立性及服务间解耦来看，proxy都不应关注具体报文的内容。proxy对业务报文的侵入，不仅加剧了proxy与A、B之间的耦合性，也使得整个系统各个服务的功能划分不清晰，为后续系统的扩展和维护都带来了困难。

 

对于这个问题，由于服务‘B’是已有系统，服务‘A’和‘proxy’则是新开发的服务，在应用层协议本身没有优劣之分的情况下，应该‘A'与’proxy‘之间的协议规范去适配’proxy’与‘B’之间的协议，这样即可保证‘proxy’在不侵入业务报文的情况下完成报文的转换。这样，‘proxy’保证了功能的独立性，也为后期的维护和扩展提供了方便。