用 iframe 来做微服务靠谱吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2395 天前的主题，其中的信息可能已经有所发展或是发生改变。

领导让我们把原有的系统各个模块拆成微服务，并独立部署，其他系统通过 iframe 来调用这个微服务,考虑到使用 iframe，有以下两个问题： 1.跨域问题，iframe 需要和父页面进行通信 2.样式问题，iframe 的样式，大小不可能和所有调用它的系统保持一致。

开发起来感觉很棘手，这种方法来做微服务合适吗？是否是最佳实践。

iframe

调用

样式

服务

32 条回复 • 2018-06-04 15:34:25 +08:00

nine99

2018-06-02 21:10:58 +08:00

这能叫微服务。。。

nine99

2018-06-02 21:11:31 +08:00

感觉他对微服务没理解吧

picture2200

2018-06-02 21:21:22 +08:00 via Android

跨域问题用反向代理拦截所有模块请求。

样式问题用固定页面大小来做。

实际上楼主领导的方案好几年前在企业 IT 流行过。狭义上讲这不是微服务。

guagusi

2018-06-02 21:24:40 +08:00

这微服务的理解也是醉

LoremIpSum

2018-06-02 21:27:23 +08:00

@picture2200 比如一个订单服务，就是一个 iframe，你提交订单后，还得跨域去通知父页面把窗口关了.蛋疼...

yidinghe

2018-06-02 21:30:00 +08:00

微服务不是这么拆分的。你要做微服务拆分，界面需要保持不变，对请求的处理逻辑再进行拆分，拆分的结果是多个后台进程之间相互调用，而不是靠浏览器去请求多个服务。

hronro

2018-06-02 21:30:06 +08:00

重新定义微服务

hronro

2018-06-02 21:31:01 +08:00

讲道理，iframe 能不用就不用吧，这东西大部分情况下可以扫进垃圾堆了

picture2200

2018-06-02 21:44:19 +08:00 via Android

@LoremIpSum 用反向代理。

例如:
首页 URL: https://xxx/

订单 URL: https://xxx/order

这样就不算跨域了。

imydou

2018-06-02 22:41:34 +08:00

aws ecs + elb 非常适合此场景

jakes

2018-06-02 22:49:57 +08:00

重新定义微服务。。。

我司 07 年的系统也是这么玩的，但是不叫“微服务”。
你的需求 #9 的方法可解。

sudoz

2018-06-02 22:50:13 +08:00

你可能对 microservice 有什么误解

lqyhk1234

2018-06-02 22:51:52 +08:00

这种方法一般是服务商向客户提供功能，优点有：
1.客户简单的在页面中嵌入所需功能
2.终端用户使用功能不需要跳转
3.服务商可以防止客户更改其逻辑和表现

比如 Paypal 的嵌入式支付窗口和 Youtube 的嵌入播放器

dobelee

2018-06-02 22:52:58 +08:00 via Android

樓主可能要把古董與現代文明相結合，你們都不懂。

phodal

2018-06-02 22:57:44 +08:00

如果是 Angular 2+ 的话，可以看看这篇相关的微服务化架构方案对比： https://github.com/phodal/micro-frontend

iConnect

2018-06-02 22:59:48 +08:00 via Android

iframe 再过阵子，都要从 http 协议中清理出去了

CFO

2018-06-02 23:08:06 +08:00 via Android

@phodal 前端圈还真是什么热点都想蹭

nakes

2018-06-02 23:19:48 +08:00

iframe?这是微服务都微到前端来了？新潮？。。

LoremIpSum

2018-06-02 23:25:21 +08:00

@picture2200 能说下这样做的弊端和好处吗

Foolt

2018-06-02 23:26:41 +08:00

你领导的意思应该是模块化，各模块独立开发，通过统一的接口与前端通信，前端整合各模块内容返回给用户。iFrame 应该只是他了解到的实现方法，你要告诉他现在的流行做法以供他参考和选择，而不是他想到什么你就直接做什么。

淘宝首页就是这样，前端以前是用 PHP 开发，后来改成 Node 了。

http://taobaofed.org/blog/2016/06/02/thing-about-taobao-homepage/

mezw

2018-06-03 01:04:19 +08:00 via iPhone

跨域问题可以用 jsonp

kookpua

2018-06-03 01:31:47 +08:00 via iPhone

@Foolt 感谢分享对我触动很大下来好好吸收实践

picture2200

2018-06-03 07:40:46 +08:00 via Android

@LoremIpSum

好处是:
1. Ajax 请求好实现，不用考虑跨域。

2. 部署停机好控制，假如在工作时段部署的话就可以先从反向代理下掉一台部署一台。

3. 反向代理的常规功能，负载均衡等等。

4. 以后可以在反向代理做网关功能，例如提前处理和加一些隐藏的 header，认证 token 等等。

picture2200

2018-06-03 07:58:43 +08:00 via Android

@LoremIpSum

坏处是

看起来很复杂。

多学习一个组件，要 tuning 反向代理。

如果反向代理需要高可用的话，需要用 dns 做 load balance 也就是 GSLB 功能。