0、写在前面的话

在过去的几天，我一直在咀嚼着关于微服务的相关概念，唯恐给自己落下一丝的不明白，也算是给自己采取的扫盲行动。毕竟也是在微服务圈子里混的人了，不把概念吃透，还怎么出去跟人家撕x呢？

讲真，身边结识的大牛也没几个，也没有什么高逼格的朋友圈，都是自己一路摸爬滚打过来的，想想几年前的自己，真替自己感到心酸。

近来常有文章提到“微服务”还没有一个相对官方的定义。

在我看来，就好像是「未婚先孕」。

在还没有准备好的时候，突然就横空出世了，而且还相当轰轰烈烈。

因此，我就寻思：我是不是该看看一些相对官方一点的文献材料呢？到底有没有定义？微服务到底是以一种什么形态存在着？

不用怀疑，《Microservices》当属最原汁原味的官方文献材料了。

《Microservices》应该算是我读过最短的论文了，整个过程（不含扩展阅读内容），大约花了我1.5个小时，算是理解了其中心思想了。

如果中间不开小差的话，1个小时读完差不多了。

1、确实没有明确定义

这是我解开的第一个困惑：关于微服务，确实没有官方正式的定义。

不仅如此，关于微服务的架构指导思想，或者说是最佳实践，也并没有出炉。

The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services.
While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

……

We've seen many projects use this style in the last few years, and results so far have been positive, so much so that for many of our colleagues this is becoming the default style for building enterprise applications.
Sadly, however, there's not much information that outlines what the microservice style is and how to do it.

请原谅我以上不负责任的总结。

Ah...

知道这个意思就好！

不过，作者还是非常精炼地向我们描述了一下什么是微服务：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

These services are built around business capabilities and independently deployable by fully automated deployment machinery.

There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

归纳起来，有以下几点：

• 整个应用系统由若干个独立运行的服务组成
• 服务之间有轻量级的通讯机制，通常是REST API
• 每个服务都有自己的业务逻辑，并且可以单独部署
• 去中心化的服务管理机制
• 每个服务可以用不同的编程语言实现，使用不同的数据存储技术

我们姑且认为这就是微服务的定义吧！

毕竟「微服务」的首创是《Microservices》这篇论文的作者，并且也得到了业界广泛的认可。

2、monolith v.s microservice

这篇论文除了「microservice」，另外还有一个高频词汇：「monolith」。

「monolith」可以理解成是传统开发模式下的“单体应用”，在《我所了解的微服务》一文中有提及到，并且将其与微服务的模式做过简单的对比。

在《Microservices》这篇论文中也不例外地将单体应用和微服务两种开发模式做了比较详细的对比。

结果呢？

当然不能让monolith输的这么难堪呀！毕竟还是有很多公司采用这种开发模式的。

通篇读下来，发现作者多次在强调单体应用的一个“软肋”:

A small change requires the entire monolith to be rebuilt and deployed.

一次小变更，就意味着整个应用要重新打包，部署。对于其他没有变更的业务模块，将会受到不小的影响。

而微服务的优越性在于独立打包，独立部署，将服务之间的影响降到最低。

此外，文中就两种开发模式的团队管理进行了讨论。

单体应用随着应用规模的不断扩大，团队规模也随之扩张，将团队划分成不同的业务线就是一个技术活，团队成员之间的沟通协作也是一个巨大的挑战，更不用说在这个团队里必须遵守统一的规约了。

微服务的高度自治的特性使得上述问题变得不那么棘手了。各个服务之间的联系是松散的，可以用不同的编程语言实现，仅靠特定的协议相互调用。关于单个服务的规模大小，一篇扩展阅读有提到过：《How big is a microservice?》

结论是：一个人，最多十几个人，最后还是不确定，大概就是要我们视情况而定吧！

不过，正是因为微服务的通信方式（lightweight mechanisms, often an HTTP resource API），导致了一部分的不确定性，也是应用出错的场景之一。因为服务之间的调用并不像单体应用那样的本地方法调用，所以可能有各种因素导致各个服务之间沟通不畅。

3、一个重要的理念

文中提及了到了微服务的一个特性：

Products not Projects
—— 做产品，而不是做项目

这其实是一种开发理念的转变。

大多数应用的开发都以软件交付为目的，开发完成后就交给运维部门管理了，项目团队也随之解散了。

而作者在文中强调，微服务的开发模式可不能这样。

整个团队应该跟随着应用的全生命周期，开发者与微服务之间建立一种微妙的连接。

亚马逊有一个著名的理念：

You build, you run it.

而后文的 Infrastructure Automation 一小节则提到了可持续集成与可持续交付，开发者通过自动化测试，自动化部署完成之后的工作。附上一张经典的pipeline示意图：

再后来的 Design for failure 一小节，提出了服务容错，快速响应，自恢复，日志记录，实时监控等特性的重要性，帮助开发者快速定位并解决问题。

Microservice teams would expect to see sophisticated monitoring and logging setups for each individual service such as dashboards showing up/down status and a variety of operational and business relevant metrics.

这样看来，不得不让我联想到DevOps！不过，谈及微服务，DevOps、容器化都是不可回避的话题。

4、微服务的未来

对于微服务的未来展望，作者还是说得很谦虚含蓄的。

作者也并没有强调今后的设计理念应该要使用微服务，而是应该根据实际的业务需求，模块划分边界以及团队自身的技术水平等因素来制定。

还是这句话：

但无论如何，微服务的架构风格值得每个公司认真去思考。

毕竟相对于单体应用，微服务的架构还是利大于弊的。

据我目前的实践经验来看，实施这套理念还是需要有一支精干的技术团队，每一个人都具备一定的开发经验，不然的话，是很难开展工作的。

如果一旦决定采用微服务架构风格了，必然要以“小步快跑，迭代试错”的节奏进入实施。

敏捷开发？我想是吧！

希望对你有所帮助。

THANKS！

每日干货分享，传递互联网世界有价值的讯息，尽在「技术汇」。