Re：从0开始的微服务架构--(二)快速快速体验微服务架构？--转

原文地址：https://mp.weixin.qq.com/s/QO1QDQWnjHZp8EvGDrxZvw

这是专题的第二篇文章，看看如何搭建一个简单模式的微服务架构。

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

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

什么是微服务架构的简单模式？

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

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

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

如何将微服务架构的简单模式落地？

落地微服务架构，重点就是发扬优势，克服缺点。如前篇文章《Re: 从 0 开始的微服务架构：（一）重识微服务架构》的对比所示，相对于单体架构，微服务架构最大的缺点是 上手难 和 运维难。

下面咱们就来看看如何从这两个方面入手，将微服务架构的简单模式落地。

上手难

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

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

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

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

第三步：经过门户后端（服务网关）将微服务 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 服务发现框架。这个方案的最大问题是：部署和运维比较麻烦。

以上三点摘自杨波先生的《实施微服务，咱们须要哪些基础框架？》

http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service#anch130564 ，

并做了部分补充，若是但愿查看这三个方案的更详细说明，推荐读一读杨波先生的文章。

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

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

只是，须要注意的是，这种方案通常是用来作 局域网内 的负载均衡，若是要为开放到互联网的服务作负载均衡，可使用 Nginx Upstream 来作。

下面是 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 是咱们团队研发的契合微服务架构的用户及权限管理系统，咱们将分享到青柳云官网，欢迎关注）将单独开发的微服务整合起来。

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

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

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

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

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

应用架构图:

 

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

 

UPMS 经过“模块”功能接入新的微服务:

 

因此，到最后，一个简单模式的基于微服务架构的系统就能够长成这样:

 

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

运维难

微服务架构的运维问题，主要是相对于单体架构来讲的。由于实施微服务架构后，整个系统的模块一会儿比原来多了不少，模块变多后，部署和维护的工做量都会变大。因此，解决运维难的问题，能够先从 自动化 的角度来解决。

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

不然，颇有可能会由于微服务架构的缺点致使咱们的团队丧失对微服务架构的信心，从而回到单体架构的老路上去。工欲善其事，必先利其器，这一点真的很重要。

 持续集成

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

 

若是没有微服务支撑平台，也能够经过 Shell 脚本的形式来调用 Jenkins API 和 Docker API。

主要过程是:

1. 调用 Jenkins 命令从代码仓库拉取代码，并打包代码。

2. 调用 Docker /build 和 /images/push 命令构建镜像，并将镜像推送到私有镜像仓库中。

3. 调用 Docker /containers/create 和 /containers/start 命令建立并启动容器。

 配置中心

在开发 / 测试环境上，程序包已经被打包成 Docker 镜像，若是能将经过测试的镜像直接推到生产环境，能够直接省去为生产环境而重复进行的打包部署工做，岂不是很美？

若是须要达到这个效果，就须要将程序包打包成具备环境无关性，也就是说，在程序包里是不能够有环境相关的配置信息的，这也就引入了 配置中心 组件。

这个组件很是简单，只是根据项目代号、环境代号和微服务代号来获取微服务所须要的键值对。例如：

ProjectA_PRODUCTION_MicroService1_jdbc.connection.url。

使用配置中心还有一个很重要的附加价值，那就是能够作到不一样环境的配置信息能够由不一样的人来管理，增强了生产环境的配置信息的安全性，例如数据库账号和密码。

这个模块也有一些开源的项目能够参考，例如百度 disconf，Spring Cloud Config。而咱们本身发杨了重复造轮子的精神，开发了一个配置中心微服务，以方便地与上面提到的 UPMS 进行整合。

注意：这一组件并非微服务架构简单模式的必需组件，只是建议使用。

 监控告警

单体应用被微服务化后，一个单体应用被拆成了不少个微服务，系统的健康巡检、性能监控、业务指标健康、文件备份监控、数据库备份监控、定时任务执行状况监控都变得困难。

因此，为了让运维的同窗能生活得踏实点，最好也能把监控平台给建了。若是但愿快速搭建监控平台，能够考虑 Nagios，Zabbix。若是但愿扩展性、可定制性更好，能够考虑使用如下组件搭建：

 

Collectd 是一款主机、数据库、网络、存储指标采集器。GitHub 上 1653 个 Star。

Metrics 是一款牛逼的 JVM 指标采集器，提供了不少模块能够为第三方库或者应用提供辅助统计信息， 好比 Jetty， Logback，Log4j，Apache HttpClient，Ehcache，JDBI，Jersey，它还能够将度量数据发送给 Ganglia 和 Graphite 以提供图形化的监控。GitHub 上 5000+ 个 Star。

CAdvisor 是一款 Docker 容器指标采集器，Google 出品。GitHub 上 6000 个 Star。

Grafana 是一款很是精美的开源仪表盘工具，支持 Graphite，InfluxDB ，MySQL 和 OpenTSDB 等多种数据源。GitHub 上 17000 个 Star。

InfluxDB 是一款优秀的开源分布式时序数据库，目前在时序数据中排名第一，它的特性中，RETENTION POLICY 能够自动地清除不须要的历史数据，很实用。GitHub 上 11175 个 Star。

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

总 * 结

在这篇文章结束的时候，咱们能够回过头来看看，咱们只须要在开发层面理解了注册中心、服务发现、负载均衡、服务网关和管理端集成框架，在运维层面准备好持续集成工具、配置中心和监控告警工具，就能够很容易地落地微服务架构，享受微服务架构带来的精彩。祝你们玩得愉快。