什么是微服务

微服务兴起已经有很多年了，也许算不上什么新技术、新架构，但不得不说，微服务改变了软件产品的设计思维。我在写这篇文章之前问过自己，写一个老生常谈的话题是否还有价值，但其实假设换个角度，如果作为我个人而言，这就是一篇新的文章，我对自己了解的技术新的一篇总结。都说一千个人眼中有一千个哈姆雷特，我想我理解的微服务大概也不会与他人完全相同，因为这里边有我个人的一些经验与理解，也希望能帮助读到这篇文章的你建立起对微服务的初步认识。

微服务是一种组织软件架构的方法，它将整体式的一个大而完整的软件架构，拆分成多个独立运作的小型服务，服务与服务之间相互独立，它们通过调用API的方式相互通信。这些独立的服务，通常由不同的小型团队负责，可以独立开发、独立部署、独立升级，而不影响到其它服务。

我找了一张整体式和微服务的图：

这也许是你看到过的最简单的微服务的图，但是抛开所有的项目信息、业务信息，我们回归到底层，这就是微服务的原型：将一个整体式的架构拆分成若干个独立的、小型的服务。

在软件研发过程中，与整体式架构相比，使用微服务的优势是非常大的。

首先就是刚提过的服务的独立性，每个服务都可以独立开发、部署、升级、运营等等，完全可以将每个服务作为单个产品来看待，服务与服务之间不需要共享代码，它们只需有一套明确定义的API就可以完成服务之间的调用及通信。

其次是服务的敏捷性。近几年国内越来越多的公司开始使用敏捷式的项目管理，这与微服务是非常契合的。这些小型服务由不同的小型团队负责管理，这些团队在小型且相对简单的环境中，可以更具针对性、更快速的工作，从而达到研发效能提升的效果。

这些小型服务是具有针对性的，一个服务解决一件事情就好，假设它慢慢扩展成了稍大些的服务，并变得复杂，那么你就可以将这个服务再次进行拆分，使其保持独立性与针对性。

微服务还有一个重要的优势是它比较弹性且容易扩展。微服务可以按需进行动态扩容，每个小型服务都可以独立扩展来满足不同的需求，这可以使团队更好地进行成本把控，并在服务需求大增或大减时保持可用性。在产品的整体架构中，假设某一服务出现故障，可能会导致程序无法运行，但是如果你使用的是微服务架构，那么你就可以切断某一功能来保证产品整体的可用性。

我在这里以汉堡店点餐举例，假设你点了套餐A，里面包括1个汉堡、一杯可乐。套餐A就相当于一个完整的产品，这个产品所包含的服务（1个汉堡、一杯可乐）是完全独立的，他们可以由不同的厨师独立制作、独立包装，只是最后它们被组装到了一起成为了套餐A。你也可以将它们作为单个产品售卖。并且每个单独的产品都具有针对性，汉堡可以填饱肚子，可乐可以解渴。汉堡店通常还会提供更多的单品以供客户扩展挑选，如果你不喜欢可乐，也可以替换成店里其它饮品，只需补差价。如果店里没有可乐了，也不会影响它们售卖除可乐之外的其它单品。

我听很多朋友讲过关于微服务的劣势，但我认为他们认为的劣势并不是真正的劣势，微服务的劣势在我看来只有一个：使用微服务架构进行产品研发成本较高。这对一些创业团队或小型团队可能并不友好。因为在软件研发阶段，使用微服务架构成本较高，并且需要比使用整体式架构更多的工作人员来组成不同的工作组，且收益并没有那么明显。这就涉及到一种选择，在设计软件架构时，是先设计成整体架构后期再拆？亦或是直接使用微服务架构进行软件研发？

由于微服务是由多个独立且小型的服务组成的一个软件架构，那便会涉及到服务与服务之间的一些通信、限制、日志等等，这时候就出现了一些针对微服务架构的服务：服务发现、边缘服务器、反应式微服务、中央配置、日志分析、分布式追踪、断路器、控制环路、集中收监控和告警、服务网格等。

这些服务我会在本专栏的后续文章中展开讲述。