微服务：通用接口设计

什么是微服务

越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

背景

现在有一个用户服务User service,该服务主要提供登陆、注册、注销等一系列跟用户相关的服务，随着业务的发展,订单服务和产品服务需要向User service 定制各种各样的新功能，此时User service的接口会变得越来越多，如下图所示:

随着定制需求越来越多，其他服务也会遇到接口泛滥同样的问题。

通用接口设计

为了解决上述接口泛滥问题，我们提出了一个通用接口的概念，那么什么是通用接口？通用接口也就是使用一个接口，搞定所有业务需求。

实现方式一：入参和出参都采用Object形式

为了解决一个接口搞定所有业务，一开始我们想到了，入参和出参都采用Object的形式，代码如下：

1public Object common(Object param){
2   //...
3   return obj;
4}


Java中的Object是一个神奇的类，它是所有类的父类，所以在Java中它能代表一切，but，当初看到这个接口的定义的时候，你肯定想骂人了，这是什么鬼，我怎么能看出人参和出参是什么，而且在实际的代码设计过程中，面对如何取object中的field也是一个难题，并且你上游的调用方肯定会抓狂忍不住会飚出WTF三个字。所以这样的接口设计被我们pass了。

实现方式二：采用Map的形式

1public Map common(Map param){
2   //...
3   return map;
4}


采用Map的好处是，如果知道key的形式，可以通过key获取入参的value，从而做出相应的逻辑处理，缺点是无法知道key的定义，也无法对入参进行校验。

实现方式三：采用Map + zk + 视图的形式

先看整体架构：

视图中心的设计非常关键，它需要非常直观的展示出入参、出参、业务方三者之间的关系；因此视图中心抽象如下:
1、params，代表入参
2、event,事件类型，代表是属于哪一个业务方调用的
3、result, 返回值

添加完接口的入参和出参关系后，需要将参数关系写入到zk，写入zk的目的是在通用接口中校验参数类型，从而避免上游的参数类型不正确。
我们看下修改后的code：

1public Map common(Map param){
2  //获取所属event
3  String event = param.get('event');
4  //获取zk参数关系数据
5  Map paramFromZk = getParamFromZk(event);
6  //参数校验
7  checkParam(param, paramFromZk);
8  // 执行相应的业务逻辑
9  Map result =  doExecute(param);
10   return result;
11}


逻辑图如下：

这样每次新的需求，只需要在视图中心做配置，就可完成功能的开发了，开发周期也可以大大的缩短；对于不同的业务，执行的业务逻辑是不同的，如果做的更抽象点，可以将业务逻辑部分抽象成一个业务引擎服务，对于相同的代码部分写一份即可，对于不同的逻辑部分，可以采用dsl语言进行动态配置，这样，每次新需求，只需要在视图中心配置参数关系，在业务引擎服务中配置dsl业务逻辑，就可以彻底完成一个功能的开发到上线了，开发效率将大大提高。

---

本公众号团队成员由饿了么、阿里、蚂蚁金服等同事组成，关注架构师之巅，可以了解最前沿的技术。