微服务架构下的移动架构实践

大家好，我是普元信息移动产品的负责人，郝振明。

很高兴又与大家见面了，今天和大家分享的主题是：《微服务架构下的移动架构实践》。

希望本次分享对大家能有帮助，也希望各位专家能够多多拍砖。

一、基于微服务的云架构是移动互联的趋势

就在前几天，马化腾在2016年腾讯“云+未来”峰会上提出：“很多传统企业过去是‘触网’，也就是使用互联网，现在开始‘触云’。越来越多企业不仅仅是使用互联网，内部业务逻辑都开始拥抱互联网，成为整个未来互联网生态的有机组成部分。目前很多新生代的企业就是从云端诞生，它的IT系统、商业模式就是基于互联网的，这些新形态的企业从一开始就完全基于云的架构来设计它整个商业模式和整个IT的基础，这是一个非常有趣的现象。”

同样，移动互联网的建设也正面向基于微服务的云架构来进行设计，这势必会对移动前端技术带来新的挑战。移动架构如何适应这种变化？面向Cloud的编程，移动端应用与之前有何不同，又如何开展研发工作？

在此之前，我们先回顾上次提到的微服务架构：

这张图是普元云平台的架构示意图（因为是示意图，难免很多细节进行了省略），今天涉及到的问题，基本上会主要集中在如下的所示部分：

1、移动应用

2、API Gateway

3、服务路由

4、服务发现

5、各种微服务

以及DevOps里的部分内容。

二、微服务架构下的移动架构演进与实现

记得一个月前，我做过一次《数字化企业云平台下的移动平台建设》微课堂，我们先回顾一下当时的一张PPT——《移动平台发展现状与趋势：移动架构的演进》。

上次分享中我提到了，移动前端经过了从竖井架构->网状架构->统一接入架构几个阶段，同时，现在开始演进到了移动平台中台化的架构。

具体可以参见：

http://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=2660392426&idx=1&sn=4b4fd5f7313707e94a3d32c55a9c2332#rd

（这里就不再赘述，如果有兴趣可以去看一下这篇分享）。

今天重点聚焦在，微服务架构下，统一接入架构的设计与实现中我的一些想法。

统一接入架构是可以避免App端与服务器端直接通信的一种方式，常见的架构里通常采用API Gateway的方式，如下图：

我简单将之前的架构图跟微服务的云架构做一个对应：

蓝色代表的是移动App端，绿色的代表是服务器端，橙色的代表了统一接入的实现（这里采用了API Gateway的方式实现）。

而服务路由和服务发现，在这里我并没有标注颜色。原因是这个是有争议的地方，我之前曾经跟行业内的人交流，有的将服务调用、服务发现以及处理部分失败的能力也放到了这个API Gateway里实现。

正如大家想到的因为微服务的应用是一个分布式系统，微服务的IP和端口很多都是动态分配的地址和端口，在API Gateway调用过程确实需要路由能力和服务发现等能力，感觉确实应该放在API Gateway，在我们的实践中，发现其存在一些问题。

最典型的是：微服务间存在相互间的访问，服务间的访问也需要通过服务中信的服务注册和发现。如果在API Gateway中做服务发现，显然会导致大量的微服务需要通过API Gateway来进行服务发现，相当不合理。

另外如果放到网络部署图中，就更加难以理解：我们稍微画一下。

你会发现，微服务间如果存在任何的访问，都需要去服务中心去调用一次服务发现，这种网络访问，在任何一家对安全较高的企业里都是行不通的。

所以，在我们的实践中，我们会将服务发现和注册的系统放入内网中，如下图：

这样带来的一个问题是：微服务之间调用是也可能存在选取调用哪个微服务的情况（地址、端口），这里可以参见顾主任（普元主任架构师顾伟）的一张PPT，如下图：

通常存在两种方式：

1、微服务调用方存在LBS能力。

2、微服务的提供者，提供Service能力。

回到之前那张PPT，通常来讲，新的微服务提供出来，虽然API Gateway可以通过服务注册中心可以及时获取到，但因微服务的实现可能存在实现协议和粒度等问题，往往不能直接让移动端使用，原因如下：

1、微服务很有可能存在，协议和实现（内部结构）有关，带来移动端代码的复杂度（比如支持个特有协议），不是很适合移动互联。

2、因微服务的粒度，可能导致移动端多次与与服务器端的通信才能完成一个场景，访问次数加大，针对移动互联这种非健壮性网络无疑是非常不可取的。

因此通常的做法是：移动端采用是API Gateway 暴露的Service（通常是封装后的），而非直接调用microservice

如下图：

如上图，移动端调用微服务采用类似的方式：

1、移动端访问的是API Gateway提供的对外API（我们一般采用Rest风格的，协议采用HTTP）。

2、这个API过程中可能调用各种微服务。在微服务调用过程中，通常会做一些协议转换（Protocal Translate）等工作。

需要说明几点：

1、对外API的实现，应该能够方便灵活调整，且需要能够做到热装载、热更新。

2、对外的API设计时，需要能够标识服务调用方的状态。针对移动端，需要获取设备信息、App版本信息等。

3、设计对外API最好统一考虑API版本，方便后续的A/B Test 和 灰度发布。

三、微服务架构下的移动的研发挑战及应对

微服务带来的研发挑战，相信关注微服务的人多少都有些耳闻，我们的经验是：办法总比困难多 。

这里我仅仅提一下通常我们在移动信息化中常遇到的几个场景：

场景一：App的UI都设计好了，微服务还没设计好。

通常的App UI设计都是以业务为驱动的，很多UI可以在前期部分或者全部确定。

而微服务是很多情况下，业务部门（或者产品经理）搞不明白，基本都是之后才有微服务的设计。

通常的做法是，讲UI做成动态无后台交互的App，实际上，这个阶段可以考虑先行设计外部API。

App的后端交互可以通过外部API进行。

这需要API Gateway有比较方便的方式注册对外服务。

场景二：移动App动态UI、后端交互都Ready，微服务却还没实现。

实际上，在微服务的情况下，无论Web还是移动App都可能存在这个问题。

我们通常的解决方案是采用统一的Mock方式，Mock系统变得非常重要，不要小看了这个系统。

场景三：移动App出了点问题，也没法本地调试，不知道问题出在哪里。

实际上，这个问题要比前面的单一问题要难以处理。

这就不得不提到监控和日志等系统了，在实现一个微服务架构时，充分考虑日志的可追溯性，并通过技术看板得以追溯。

通常每一笔日志都会记录全局流水号用于跟踪业务。

我们大致采用如下的日志格式：

[日志类型] [记录时间] [全局流水号] [请求编号] [调用边界]［组件类别］［行为］［资源名］[登录用户名] [ip] [消息ID|响应ID] [响应消息ID] [来源系统] [目标系统] [当前节点实例ID] [线程ID] [当前内存总量] [当前空闲内存] [自定义信息]

举例：

终端请求接入示例：

[S][2016-05-31 08:31:00.883][12348809550430430155043884eb5678][40288809550430430155043884eb00d2][CALLED][][Begin][/actions/001][sysadmin][10.10.10.10][40288809550430430155043884eb00d2][][][portal-server][portal-server01][100][428120K][133184K][xxxxxxx]

系统间调用示例：

[S][2016-05-31 08:31:00.883][12348809550430430155043884eb5678][40288809550430430155043884eb00d2][CALL][][Begin][/actions/001][sysadmin][][40288809550430430155043884eb00d2][][portal-server][vcs][portal-server01][100][428120K][133184K][xxxxxxx]

这些都是微服务的云架构中统一考虑的。

总结一下：

基于微服务的云架构作为移动系统的后端已经是必然的趋势，在这种情况下，移动的架构具有以下的趋势：

1、采用统一接入的方式，行业内一般采用API Gateway。

2、API Gateway 本身可以具有服务路由的能力，但不建议将服务注册和发现放在其中。

3、针对服务的注册信息，API Gateway可以通过订阅的方式与服务注册中心交互。

4、移动端不建议直接调用microService，而建议调用对外的API。

5、API Gateway中的能力需要提供热加载、热更新的能力。

结合微服务体系下移动的研发，我们的经验是：

1、App的实现以来对外的API，不依赖的microService。

2、App的调试，前期可以基于Mock的方式

3、App功能问题定位，在微服务架构行有时候需要依赖日志的规范性。

普元云计算专区：http://primeton.csdn.net/m/zone/primeton/index#

普元公众号：