快速正确的搭建一个微服务架构需要了解的那几个点

原文:https://my.oschina.net/u/3636867/blog/1803023

作者:烂猪皮

一、微服务架构四大特性

好的微服务架构是什么样的呢？想要搭建好一个微服务架构，必须要具备一下四个特征：

服务的粒度需根据业务功能来划分，对于某些复杂的业务来说，可能粒度较大，对于相对简单的业务而言，可能粒度较小。总之，服务的粒度可大可小，但往往我们更希望它尽可能的小，但又不希望服务之间有任何的依赖，因此粒度的划分是非常考验架构师水平的事情。

我们需要确保每个微服务只做一件事情，也就是我们经常提到的“单一职责原则”，该原则对服务的划分提供了指导方针。

每个服务相互隔离，且互不影响。也就是说，每个服务需在自己的进程中运行。众所周知，进程之间是隔离的，是安全的，而进程内部或线程之间资源是共享的。换句话说，一个服务出了问题，不会影响到其它服务受到任何影响。

随着业务功能不断增多，服务的数量也会逐渐增加，我们需要对服务提供自动化部署与监控预警的能力，才能更加高效地管理服务。

二、搭建一个微服务架构

记得好久之前看到一个大牛说过：如果单体架构都搞不好，就别搞微服务架构。乍一看，这句很有道理，后来发现这句话是不太对的，因为微服务架构的目的就是为了降低系统的复杂性，所以 微服务架构应该比单体架构更简单、更好实践才对。

这篇文章，我们就分享一下如何搭建一个 简单模式的微服务架构。

何谓微服务架构的简单模式？

相对于大型互联网平台动辄几万并发的访问量，或者每天多次的在线版本发布，绝大多数企业和项目并没有这样的需求。他们关注的是如何更好地提高开发效率，如何更快地实现新需求，如何更便利地运维，等等。

微服务架构的简单模式就是可以满足以上需求的软件架构方案。

相对于“完美”的微服务架构方案，微服务架构简单模式可以暂且不用关注保障数据一致性的分布式事务技术、方便程序包在环境间（开发、测试、生产）迁移的配置中心组件、监控 API 调用情况的调用链组件、避免系统超载的断路器组件、方便 API 管理和测试的 API 文档框架、Zookeeper、Redis，以及各种 MQ。只需要关注常常谈到的 注册中心、服务发现、负载均衡和 服务网关即可。

如何落地？

落地微服务架构，重点就是发扬优点，克服缺点。相对于单体架构，微服务架构最大的缺点是 上手难 和 运维难。下面我们就来看看如何从这两个方面入手，将微服务架构的简单模式落地。

上手难

相对于传统的单体架构，微服务架构一下子引入了太多的概念，让新手有点无可适从。所以，我们更要去芜存菁，理清楚哪些是自身需要的，哪些只是江湖上的传说。下面就来看看哪些组件是开发一个微服务架构的系统所必需的。

首先说一下，使用微服务简单模式进行开发的四个步骤：

第一步：沿用组织中现有的技术体系开发单一职责的微服务。

第二步：服务提供方将地址信息注册到注册中心，调用方将服务地址从注册中心拉下来。

第三步：通过门户后端（服务网关）将微服务 API 暴露给门户和移动 APP。

第四步：将管理端模块集成到统一的操作界面上。

为了实现以上 4 点，相对应的就是下面必需掌握的基础技术（必需的组件）。

注册中心、服务发现、负载均衡：对应上边第一步与第二步

服务网关：对应上边第三步

管理端集成框架：对应上边第四步

注册中心、服务发现、负载均衡

和单体架构不同，微服务架构是由一系列职责单一的细粒度服务构成的 分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个 服务注册发现 问题，也就是说服务提供方要将自己的服务地址注册到某个地方（服务注册中心， Service Registry Center），服务的调用方可以从服务注册中心找到需要调用的服务的地址（服务发现，Service Discovery）。同时，服务提供方一般以集群方式提供服务，也就引入了 负载均衡 的需求。

根据负载均衡（Load Balancer，简称 LB）所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种：

集中式 LB 方案

第一种是集中式 LB 方案，在服务消费者和服务提供者之间有一个独立的 LB，LB 通常是专门的硬件设备如 F5，或者基于软件如 LVS，HAproxy 等实现。

服务调用者调用服务时，向 LB 发起请求，LB 再根据一定的策略（比如轮询、随机、最小响应时间、最小并发数等等）将请求路由到指定的服务。这个方案的最大问题是：调用者和提供者之间增加了一跳，LB 也最有可能成为整个系统的瓶颈。

进程内 LB 方案

第二种是进程内 LB 方案，针对集中式 LB 的不足，进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案。

其原理是：服务提供者将自身的地址发送到服务注册中心，同时定时发送心跳给注册中心，注册中心按心跳情况判断是否将此节点从注册表中摘除。服务调用者调用服务时，先从注册中心拉取服务注册信息，然后根据一定的策略去调用服务节点。

这种情况下，即使注册中心宕机，调用方也可以根据内存中已经拉到的服务地址将请求路由到正确的服务上去。这个方案的最大问题是：服务调用者可能需要集成注册中心的客户端，即将来注册中心服务端升级，可能会需要升级注册中心客户端。

主机独立 LB 进程方案

第三种是主机独立 LB 进程方案，该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将 LB 和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡。该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架。这个方案的最大问题是：部署和运维比较麻烦。

当下，随着 Netflix 的微服务方案和 Spring Cloud 的兴起与成熟，第二个方案 成为我们的首选。我们推荐使用 Eureka 做服务注册中心，Ribbon 做客户端服务发现和负载均衡。

这个选择的最大好处是 简单 + 实用 + 可控，不用引入额外的 Zookeeper、Etcd 做注册中心，部署和运维也都比较简单。从代码上来说，使用起来也非常简单。

只是，需要注意的是，这种方案一般是用来做 局域网内 的负载均衡，如果要为开放到互联网的服务做负载均衡，可以使用 Nginx Upstream 来做。

在此我向大家推荐一个架构学习交流群。交流学习群号：575745314 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

下面是 Eureka 最重要的几个参数配置，从这些参数也可以大概看看 Eureka 是如何工作的。

由于 Eureka 的注册及过期机制，服务从启动到完全可用需要近 2 分钟的时间，所以，为了提高开发及测试环境中的发版速度，我们改了以下几个参数。生产时，一定要改回去。

Eureka 注册中心的界面如下：

详细信息可参考

https://github.com/Netflix/eureka

和

https://github.com/Netflix/ribbon。

服务网关

通常，一个大系统里会有很多职责单一的微服务，如果门户系统或移动 APP 来调用这些微服务的 API 时，至少要做好两件事：

由统一的入口来调用微服务的 API

API 鉴权

这就需要一个 服务网关。2015 年，我们使用 Rest Template + Ribbon 做了一个简单的 API 网关。原理就是当 API 网关接到请求 /service1/api1.do 时，将请求转发到 service1 对应的微服务的 api1 接口。

后来，发现我们实现的功能，Spring Cloud Zuul 都有比较好的实现，也就切换到 Zuul 上面去了。Zuul 是 Netflix 基于 Java 开发的服务端 API 网关和负载均衡器。

除此之外，Zuul 还可以对过滤器进行动态的加载、编译、运行。最令人吃惊的是，Zuul 的转发性能据说和 Nginx 差不多。详细信息可参考 https://github.com/Netflix/zuul。

总的来说，一般情况下，API 网关（可以称为门户后端）用来进行反向代理、权限认证、数据剪裁、数据聚合等。

管理端集成框架

掌握注册中心、服务发现、负载均衡和服务网关技术后，微服务已经可以为门户系统和移动 APP 提供可靠服务。但是，给后台运营人员使用的管理端是怎么实现的呢？

由于后端运营系统的压力不大，我们可以通过 CAS 和 UPMS（UPMS 是我们团队研发的契合微服务架构的用户及权限管理系统，我们将分享到青柳云官网，欢迎关注）将单独开发的微服务整合起来。

三步集成一个微服务的基本过程就是：

在微服务中引入基于 Spring Boot 的 security starter，starter 里包含了系统的顶端 Banner 和左侧菜单。

将微服务的访问地址注册到 UPMS 中，这个地址作为此微服务的入口菜单（一级菜单）。

在 UPMS 中配置微服务的功能菜单及角色权限信息。

用户从浏览器打开一个微服务的时候，security starter 会调用 UPMS 的 API 拉取所有的微服务清单（一级菜单）和当前微服务的功能清单（二级菜单），并将当前微服务的页面在内容区展现给用户。

应用架构图：

UPMS 截图，橙色部分由 UPMS 框架提供，红色框为微服务的页面：

UPMS 通过“模块”功能接入新的微服务：

所以，到最后，一个简单模式的基于微服务架构的系统就可以长成这样：

至此，基本的微服务架构已经搭建起来。下面来聊聊怎么解决微服务运维的问题。

在此我向大家推荐一个架构学习交流群。交流学习群号：575745314 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

运维难

微服务架构的运维问题，主要是相对于单体架构来说的。因为实施微服务架构后，整个系统的模块一下子比原来多了很多，模块变多后，部署和维护的工作量都会变大。所以，解决运维难的问题，可以先从 自动化 的角度来解决。

更进一步，如果希望更好地发挥微服务架构的优势，规避缺点，则建议准备一个可靠的基础设施，包含自动构建、自动部署、日志中心、健康检查、性能监控等功能。

否则，很有可能会因为微服务架构的缺点导致我们的团队丧失对微服务架构的信心，从而回到单体架构的老路上去。工欲善其事，必先利其器，这一点真的很重要。

持续集成

单体应用被微服务化后，很有可能从原来的一个程序包分成了 10 个、20 个甚至更多的程序包。那么，我们首先遇到的麻烦就是部署工作直接扩大了 10 - 20 倍。这时，持续集成的方法和工具就成了实施微服务架构的前提条件。我们在实践过程中，利用基于 Docker 的容器服务平台自动部署整个系统的微服务。其过程如下图：

配置中心

监控告警

除了以上模块，我们还开发了一个模块，用来探测应用程序的健康情况和性能，在主机、程序健康情况、程序性能等各种指标出现异常时，发送警报给运维人员。

最后

在这篇文章结束的时候，我们可以回过头来看看，我们只需要在开发层面理解了注册中心、服务发现、负载均衡、服务网关和管理端集成框架，在运维层面准备好持续集成工具、配置中心和监控告警工具，就可以很容易地落地微服务架构。