6 张图带你搞懂微服务
虽说 微服务 早已是一个老生常谈的话题了，在 infoq 或者 thoughtworks 上可以找到很多案例，不过可惜的是其中相当比例的案例是失败的案例，究其原因，除了 技术门槛 之外，主要是因为很多人脱离了实际情况，只是为了微服务而微服务。本文通过一个例子带领大家从头到尾体验一下微服务的演化过程，不仅要做到知其然，更要做到知其所以然。
假设我们正在开发一个在线购物项目，其主要功能包括商城、推荐、评论、用户等，它是一个典型的 单体架构 ：不同团队的技术人员工作在同一个版本库上，系统功能按模块划分，不同模块之间通过本地函数调用，通常操作同一个数据库。
当我们把单体架构切分成独立的服务之后，原本模块间本地的函数调用变成了服务间远程的 RPC 调用，我们不得不处理服务治理之类的问题，随着微服务数量的增加，问题会变得越来越棘手，好在随着云原生的发展，特别是 K8S 和 istio 等技术的成熟，我们的架构可以演化到 service mesh 阶段，通过 sidecar 透明实现服务治理。
服务部署好了之后，接下来我们还需要考虑如何暴露服务以供前端调用，比如用户浏览某个商品的详情页，内容包括商品数据、以及对应的推荐数据和评论数据，如果直接操作服务的话，那么需要多次查询商品服务、推荐服务、评论服务，并不可取，此时可以加入 API Gateway 充当代理，前端只要请求 API Gateway 一次就可以拿到数据。
微服务是个极其复杂的概念，本文仅就一些表面问题浅谈一二，其他诸如 SAGA 之类的复杂问题，由于篇幅所限，并未涉猎，大家如果有兴趣的话请自行查阅。
最后把 Martin Fowler 在 PoEAA 中提出的 分布式对象第一定律 送给大家：不要分布你的对象！套用这个说法的话，不难引申出微服务第一定律：不要使用微服务！虽然话里有一些戏虐的成份，但是它至少告诫我们在面对微服务的时候要怀揣着一颗敬畏的心。
本文文字及图片出自 InfoQ
共有 1 条讨论