聊一聊微服务的一些基础架构，入门篇

微服务这几年不可谓不火，很多技术团队都开始在自己的项目上引入了微服务。一方面这些团队确实很好的推动了微服务的应用和发展，另一方面也可以看到一些盲目追技术热点的行为所带来的危害，比如很多中小团队对微服务的基础知识只是做了很浅显的了解就开始盲目的推动微服务的实施，最后导致了项目的失败。

微服务要想做好是一个非常复杂的架构，今天就先只聊一聊微服务的一些基础架构，算是入门篇。

一、什么是「 微服务 」？

「 微服务 」由 Martin Fowler 提出，它是指一种软件架构风格。一个大型的系统可以由多个微服务组成，每个微服务是被独立部署，独立完成自己的任务单元，微服务之间是通过API方式进行通信调用，是松耦合的。

这个模式听着是不是很熟悉的感觉？

因为在提出「 微服务 」概念之前，很多互联网公司的中大型项目早就是按照将业务拆分成独立单元的形式在部署和架构的，这与微服务的思路是一脉相通的，只不过实现方式没有现在这么规范与体系。

那「 微服务 」到底是怎么演变过来的呢？

在做一个新项目的时候，一开始项目大多数都很小，都是「 单体应用 」，这是很常见的做法。在项目规模小的时候，这种方式开发效率和运维效率都最高，符合互联网公司快速响应的要求。

但是随着业务量越来越大，项目也越来越复杂，开发团队人员也越来越多。这个时候还采用单体应用，问题就会很明显了。下面挑选两个最为常见的问题来举例：

协同问题：多个人同时开发一份代码，在工作协同上就会经常遇到代码冲突问题。

可用性问题：因为是单体应用，即使改个最小的功能，也需要整体发布，不仅直接影响了线上可用性，还可能会对正常功能带来风险。

为了解决这些问题，大家就开始考虑将「 单体应用 」进行拆分，进行服务化部署。然后又随着 Martin Fowler对「 微服务 」概念的提出，加上 DevOps 的流行，进一步促进了微服务的火热发展。

「 微服务 」的理念提倡每个服务都是单一职责，且每一个服务都能实现自治，因此可以带来一些明显好处：

部署简单：每个微服务都可以独立去部署，方便快捷。

逻辑清晰：将一个独立功能逻辑封装在单一微服务里面，实现整体项目的逻辑清晰。

可扩展：因为可以随时增加和减少微服务，可以很方便的扩展功能。

可靠性高：某一个功能的异常可以隔离在单一微服务里面，可以提高整体可靠性。

二、「 微服务 」的架构是什么样？

我们先来看一下「 微服务 」的架构图：

（图片来源网络，粉丝太少就懒得画图了，大家发挥一下想象力将就的看看，哈哈）

看起来挺复杂对不对，事实上也确实很复杂。

所以微服务并不是适用于所有项目、所有团队的。在应用之前一定要搞清楚是否适合自己。

要保证这么一套微服务架构能成功运行起来，我们起码需要以下这些微服务的基础组件：

服务注册

部署了一个微服务节点，得让调用者知道啊，当微服务节点有增加或减少的时候，也得让调用者及时知晓啊。这些问题都是通过“服务注册”组件来实现的，服务提供者将自己的服务地址等信息登记到“服务注册”组件中，调用者需要的时候，每次都先去查询“服务注册”即可。免去人工维护微服务节点的信息同步问题。

服务网关

是指提供给外部系统调用的是统一网关。主要做安全和权限控制等。

配置中心

微服务的配置中心是用来统一管理所有微服务节点的配置信息的。因为同一个程序可能要适用于多个环境，所以在微服务实践中要尽量做到程序与配置分离，将配置进行集中管理。包括微服务节点信息、程序运行时配置、变量配置、数据源配置、日志配置、版本配置等。

服务框架

是指用来规范各个微服务节点之间通信标准的。服务间通信采用什么协议、数据是如何传输的、数据格式是什么样的。有了这个统一的“服务框架”就能保证各个微服务节点之间高效率的协同。

服务监控

微服务运行起来之后，为了能够监控节点的健康情况，保障节点的高可行，需要对各个服务节点进行收集数据指标、然后对数据进行实时处理和分析，形成监控报表和预警。

服务追踪

一旦使用了微服务架构，那么当有请求过来时，就会经过多个微服务节点的处理，形成了一个调用链。为了进行问题追踪和故障的定位，需要对请求的完整调用链进行记录。

这里的服务追踪与上面的服务监控是不同维度的，一个是全局的，一个是微观的，发挥的作用也不一样。

服务治理

就是指需要通过准备一些策略和方案，来保障整个微服务架构在生产环境遇到极端情况下也能正常提供服务的措施。比如 熔断、限流、隔离等等。

当然，上述只是一个微服务架构最为核心的基础组件，一旦微服务体系过大，例如有几十上百个微服务节点，那么开发、维护、测试的成本就会非常大。因此一般还会引入 自动化部署 和 自动化测试 来提高协同效率。

三、「 微服务 」入门如何避免踩坑？

你以为微服务架构都是下面这样的吗？

事实上，更能是下面这样的，哈哈。

（图片来源网络）

大家都在宣扬「 微服务 」多么多么的好，例如：易扩展、松耦合、服务简单、独立开发、易维护、轻量级等等。虽然这些优势也是事实，但是「 微服务 」带来的问题也很多，尤其是对于刚入门的团队而言，应用微服务后，趟坑真的可以趟到你崩溃。下面就普及一些常见的问题来给大家打个预防针：

不是所有项目都适用微服务

有些项目规模还比较小，或者项目才刚立项启动，也只有三四个人负责开发维护，这时候是不建议一上来就搞微服务架构的。这种情况下搞微服务，不仅是“杀鸡用牛刀”，而且还无谓的增加了项目的复杂度，本身一个单体结构就可以搞定的事情，非得拆分N多节点，人员又不足以支撑这么多节点的开发维护，这完全是自找苦吃。反而是等项目成熟了、规模大了之后，再开始慢慢将原有结构拆为微服务才是正确的做法。

不要拆分过多过细的服务

即使项目经过评估后适合拆为微服务架构，但也不要过度拆解。有的团队喜欢将项目拆成很细很细的颗粒，最后把项目搞的特别复杂，整个团队都陷进去了。

拆分服务的颗粒度应该根据业务发展和团队现状综合去考虑。这里可以参考一个很火的理论「 康威定律 」。什么样的团队，就产生什么样的架构，微服务拆分的颗粒度是需要和团队结构相匹配的。当你着手拆微服务的时候，得先评估一下团队人员和素质，一般在开发期，2-3个人开发一个服务是合理的，在维护期，1个人维护2-3个服务也是合理的。

如果拆分过细，开发人员跟不上，会严重降低大家的工作效率。并且过细的服务，会导致一个请求的调用链条很长，不仅会影响请求的响应时间，也会对线上问题排查带来增加难度。

没有DevOps就不要急于微服务

一个稳定的微服务架构，是需要 持续集成、自动化部署、自动化测试、健全的监控体系来保障的。如果团队还不具备DevOps，这些基础的建设都没有做好，一上来就搞微服务的话，就会导致实施过程中问题百出，微服务的优势不能发挥。

以上，就是对架构设计中「 微服务基础 」的一些思考。