架构设计之「 微服务入门 」

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

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

1、什么是「 微服务 」？

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

这个模式听着是否是很熟悉的感受？

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

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

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

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

• 协同问题：多我的同时开发一份代码，在工做协同上就会常常遇到代码冲突问题。

• 可用性问题：由于是单体应用，即便改个最小的功能，也须要总体发布，不只直接影响了线上可用性，还可能会对正常功能带来风险。

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

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

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

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

• 可扩展：由于能够随时增长和减小微服务，能够很方便的扩展功能。

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

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

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

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

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

因此微服务并非适用于全部项目、全部团队的。在应用以前必定要搞清楚是否适合本身。

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

• 服务注册

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

• 服务网关

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

• 配置中心

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

• 服务框架

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

• 服务监控

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

• 服务追踪

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

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

• 服务治理

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

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

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

你觉得微服务架构都是下面这样的吗？

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

（图片来源网络）

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

• 不是全部项目都适用微服务

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

• 不要拆分过多过细的服务

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

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

  若是拆分过细，开发人员跟不上，会严重下降你们的工做效率。而且过细的服务，会致使一个请求的调用链条很长，不只会影响请求的响应时间，也会对线上问题排查带来增长难度。

• 没有DevOps就不要急于微服务

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

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

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。😊

本文原创发布于微信公众号「 不止思考 」，欢迎关注。涉及 思惟认知、我的成长、架构、大数据、Web技术 等。