微服务介绍

微服务是一种构建程序的方法，或者说理念。因此它没有具体的条例，一定要如何如何。架构通常是在实际项目中起到一个构建基础骨架的作用，就好像画画的时候，首先画的草图。那么微服务作为一种类型架构，或者说是架构的方法，它在实际的项目当中起到指导的作用。

微服务的核心理念是将庞大的单体式应用分解为多个较小的微服务应用。每个微服务高度内聚，拥有自己的运行环境，独立的逻辑，甚至独立的数据库。

实际项目过程中，我们就会依照这样的思路进行程序的架构。当然，程序架构的方法不单有微服务这一种，实际项目过程当中，我们也会根据实际情况进行架构的选择。下来，我们深入探讨微服务架构的理念。

1. 为什么我们需要微服务

任何新技术的诞生，一定是解决历史遗留的问题的。所以，技术类图书章，通常会讲这门技术的诞生背景。很多人会跳过这些章节，这其实是非常不正确的学习方法。

我们学一门新技术的时候，尤其是你已经掌握这个范畴中的“旧技术”的时候，这个诞生背景能让我们清楚这个技术相比较旧的技术，优势在哪里，更适合哪些应用场景。在学习的过程中，就可以不断的和已掌握的旧技术进行对比和参照。这样有目的的学习，会让你更深刻的理解这个技术，并且会和已掌握的技术串成一整套体系。这样，无疑在实际项目做技术选型的时候更有把握。

那么，微服务究竟解决了什么样的历史遗留问题呢？

回顾之前的技术架构

技术架构的变迁是很复杂，细节并且线性的改进，不同的技术架构之间也会有相互的融合点。因此这里以我自身的理解，大致把之前的技术架构变迁抽象出几个节点，并予以简述。

技术架构听起来是个非常“高大上”的技术词汇，总会让初学者望而却步。实际上，技术架构存在在每一个应用程序中。我们自己写过的小程序，小应用都可以给它安上一个“高大上”的技术架构思维。

面向过程

学习编程语言的人通常会把 C/C++ 作为学习的门编程语言，所以自然也很清楚 C 是面向过程的，C++ 是面向对象的。技术架构也可以这么看待，我们开始用 C 语言写过的“算法题”都可以看作是面向过程的架构。因为每个函数都完成程序的某一部分过程，在主函数里，我们依次把这些过程合理的排列，就成了一个简单的面向过程的应用程序。

面向对象

随着程序的复杂度越来越高，面向过程使得整个程序变得异常的杂乱。因此我们开始使用 C++，开始面向对象的技术架构。在面向对象的架构中，认为一切事物都可以抽象为一个 Class，我们把具有相同属性、方法的事物封装为一个类，再利用继承实现类的多态。这样的架构中，代码变得非常清晰和干净。架构的思路也符合我们对于客观世界的理解。

SOA（面向服务的体系结构）

随着系统的复杂度提升，面向对象也开始凸显出了它自身的问题。面向对象使得业务模块被分离在代码的各个角落。每个业务模块都依赖多个类对象的实现。那么，在维护和扩展时，将会变得非常麻烦————因为，一个业务的更改，会涉及到多个类对象的实现。我们需要把代码翻来覆去的修改。

因此，我们便有了 SOA————面向服务的技术架构。SOA 不再关注事物（Class）的抽象，而转而关注对于接口（interface）的抽象，对于服务的抽象。

我曾经看到过这样一个比喻，我觉得非常贴切。一个创业公司，开始非常小，就几个人。于是我们就把每个人能做的事都列出来，遇到问题就去找能处理这个问题的人。随着公司越来越大，管理会越来越混乱。于是我们开始划分部门，研发部门负责研发，人事部门负责人事。这就是面向服务的结构体系。

我们把服务进行抽象分离，每个服务完成自己内部的事情。把抽象的依据转移为服务，而不再是关注每个类对象本身。

2. 微服务架构

实际上，SOA 是一个更广泛化的定义，微服务架构可以看作是 SOA 的升华，在面向服务的基础上，更深入的、更细粒度的抽象。

继续以公司的例子来说，每个部分我们划分好了，然后发现各个部门之间不可避免的要相互协作，因此我们又独立出一个管理部门（ESB 企业服务总线），专门负责对公司所有部分进行管理和协作。也就是说，我们在内部划分了部门，进行了业务的分离，但是在对外时，我们又必须通过管理部门把所有业务整合为一个整体。这样产生的问题是，现在的应用程序更新迭代越来越快，每个业务变更都会影响到这个服务集群的整体。比如公司研发部不断要添加新的开发人员，原本的开发人员负责的职务可能也会随着公司需求不断地发生变化，那么，研发部就需要不断地去跟管理部门报告。如果某个服务出现问题，那么整个服务整体都将陷入瘫痪。

因此，微服务以更细的粒度对程序进行面向服务的分离。每个服务拥有自己独立的运行环境，自身运行、维护、可用性都不依赖于其它服务。微服务的架构要求每个微服务应用具体更强的可用性，通过暴露的接口进行服务间的协作。微服务架构完全的去中心化，不需要“管理层”的介入，部门间可以通过暴露的服务接口进行协作。是不是有点类似于现在创业公司提倡的扁平化管理？

3. 总结

总而言之，微服务在组件化、模块化的程度上更加彻底。把每个模块进行更抽象的分离，将每个模块内聚为一个可独立运行，拥有独立环境的微服务应用程序。

这有点类似于谷歌公司的模块化手机，把手机拆分为一个一个独立的功能模块，在实际使用时，可根据实际需求进行合理的拼合组装。而我们现在的手机就类似于 SOA 面向服务体系结构，手机内的每个部件也是模块化的，但是我们把它组合成为了一个不可分割的整体，因此我们手机某一个部件出问题的时候，我们还是要兼顾到其它部件。比如我手机屏幕碎了，那我必须去找到我这款手机的屏幕，才能匹配替换。而微服务架构，也就是模块化手机中，就完全没有这个限制。

所以，微服务在系统复杂度很高的情况下，提供了一个非常不错的架构理念和方式————即把各个模块抽象为独立的微服务应用。使得我们在架构编码，维护扩展都变得更加容易和清晰。