微服务技术架构设计最佳实践.docx

?

?

你设计的服务是“微”服务还是“危”服务

微服务技术架构设计最佳实践

?

?

架构的演变过程经历了从单体架构、SOA架构、微服务架构，再进入容器化，如今又流行无服务架构，虽然架构在逐步在升级，但是随着业务量的发展会发现版本迭代频率会逐步频繁，随之而引发的代码冲突、模块耦合问题似乎并没有减少。既然都已经是微服务架构了，怎么还是会出现这样的问题呢？架构师们宣导的微服务的优势不是已经解决了这些问题吗？为什么微服务的这些优势在项目中并没有很好的体现出来呢？以下是在实际工作中遇到若干真实案例，我们看看微服务是否真的解决了所面临的问题。

一、多分支条件

笔者从事的行业是为银行提供金融科技服务，实现银行数字化转型，与银行对接过程中会高频的和银行的内部系统交互的情况，系统与系统之间是通过ESB的方式来通讯。架构设计思路为了屏蔽业务系统和ESB的耦合，独立了银行网关服务，目的是将RPC请求换为ESB请求。同时业务系统自身也会暴露ESB服务给合作伙伴调用以及行内业务系统异步回调。整体架构如下图所示：

随着项目逐步推进，会发现银行网关代码冲突现象以及Bug出现频率明显提高。出现了因一个问题引发其他bug的现象，修复Bug的效率明显降低，项目进度明显降低，通过深入分析后发现问题的根源出现在代码层面。例如以下代码，设计初衷是针对ESB给出不同的actionCode做不同的业务处理，而且项目初期接入的系统比较少，简单的IF、ELSE判断就能解决，随着接入系统逐步变多，整个代码变成不可控局面，相关代码如下。

StringnotifySystem(StringactionCode,StringrespBody){if(actionCode.equals(A01)){//业务逻辑处理return;}elseif(actionCode.equals(A02)){//业务逻辑处理return;}elseif(actionCode.equals(A03)){//业务逻辑处理return;}elseif(actionCode.equals(A04)){//业务逻辑处理return;}elseif(actionCode.equals(A05)){//业务逻辑处理return;}return;}

当项目进入SIT阶段时会发现这个通知类已经出现N多个分支条件，会有一堆人同时在修改这份代码，代码被覆盖、合并冲突、合并错误等问题高频出现。此时你还敢说你的服务是“微”的吗？那么，为什么采用了微服务架构思想来设计系统，而且服务划分的也很合理，但是在编程阶段“微服务”却变成了“危服务”呢？事实上无论是单体架构还是微服务架构，在进入编码阶段需要关注开闭原则和单一原则这二大原则。

开闭原则（对于扩展是开放的，但是对于修改是封闭的）：软件实体（模块、类、函数等）应该可以扩展，但是尽量不要做不必要的修改。

单一原则（规定一个类应该只有一个发生变化的原因）：修改任何类型的分支逻辑代码，都需要只改动当前类的代码。

上述的例子其实就是一个非常典型的多分支处理场景，尽管使用微服务架构，而且设计了合理的服务拆分策略，但是并不能解决多分支判断的情况。在开发过程中要求架构师或者技术经理能经常性的审查代码，一旦发现代码变成不可控局面是，要求研发人员去尽早重构代码，把不可控变成可控。例如本例则可以通过策略方式来实现多分支的场景条件判断，实现对修改关闭，对扩展开放的设计思路。所谓策略模式简单说分二步：

1、定义一个接口，用来定义需要具体处理的方法

2、定义一个Map来存放具体策略对象，其中key是对应actionCode，value是具体的实现类

策略模式实现方式如下：

1、先定义接口ESBHandler，用来约束策略需要实现的方法

publicinterfaceESBHandler{

StringhandlerESBRequest(Stringebsxml);

StringactionCode();}

2、定义策略的具体内容，假设支付通知的actionCode=A02，定义一个支付通知处理类PayNoticeHandler

@ServicepublicclassPayNoticeHandlerimplementsESBHandler{@OverridepublicStringhandlerESBRequest(Stringebsxml){