虽说 微服务 早已是一个老生常谈的话题了,在 infoq 或者 thoughtworks 上可以找到很多案例,不过可惜的是其中相当比例的案例是失败的案例,究其原因,除了 技术门槛 之外,主要是因为很多人脱离了实际情况,只是为了微服务而微服务。本文通过一个例子带领大家从头到尾体验一下微服务的演化过程,不仅要做到知其然,更要做到知其所以然。

假设我们正在开发一个在线购物项目,其主要功能包括商城、推荐、评论、用户等,它是一个典型的 单体架构 :不同团队的技术人员工作在同一个版本库上,系统功能按模块划分,不同模块之间通过本地函数调用,通常操作同一个数据库。

当我们把单体架构切分成独立的服务之后,原本模块间本地的函数调用变成了服务间远程的 RPC 调用,我们不得不处理服务治理之类的问题,随着微服务数量的增加,问题会变得越来越棘手,好在随着云原生的发展,特别是 K8S 和 istio 等技术的成熟,我们的架构可以演化到 service mesh 阶段,通过 sidecar 透明实现服务治理。

服务部署好了之后,接下来我们还需要考虑如何暴露服务以供前端调用,比如用户浏览某个商品的详情页,内容包括商品数据、以及对应的推荐数据和评论数据,如果直接操作服务的话,那么需要多次查询商品服务、推荐服务、评论服务,并不可取,此时可以加入 API Gateway 充当代理,前端只要请求 API Gateway 一次就可以拿到数据。

微服务是个极其复杂的概念,本文仅就一些表面问题浅谈一二,其他诸如 SAGA 之类的复杂问题,由于篇幅所限,并未涉猎,大家如果有兴趣的话请自行查阅。

最后把 Martin Fowler 在 PoEAA 中提出的 分布式对象第一定律 送给大家:不要分布你的对象!套用这个说法的话,不难引申出微服务第一定律:不要使用微服务!虽然话里有一些戏虐的成份,但是它至少告诫我们在面对微服务的时候要怀揣着一颗敬畏的心。

本文文字及图片出自 InfoQ

余下全文(1/3)

本文最初发表在wkee.net,文章内容属作者个人观点,不代表本站立场。

分享这篇文章:

请关注我们:

《6 张图带你搞懂微服务》有1个想法

  1. admin  这篇文章, 并对这篇文章的反应是俺的神呀赞一个

发表评论

邮箱地址不会被公开。 必填项已用*标注