微服务架构下的移动架构实践
微服务架构下的移动架构实践
普元云计算 发表于11个月前
微服务架构下的移动架构实践
  • 发表于 11个月前
  • 阅读 10
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 十分钟定制你的第一个小程序>>>   

郝振明  EAII企业架构创新研究院

转载本文需注明出处:EAII企业架构创新研究院,违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复此公众号:“加群 姓名 公司 职位 微信号”。




大家好,我是普元信息移动产品的负责人

郝振明。

很高兴又与大家见面了,今天和大家分享的主题是:

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

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



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


就在前几天,马化腾在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功能问题定位,在微服务架构行有时候需要依赖日志的规范性。


本次分享结束,感谢大家的收听,谢谢大家!


共有 人打赏支持
粉丝 2
博文 23
码字总数 18356
×
普元云计算
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: