如何快速搭建一个微服务架构?

发布时间: 2021-11-30 04:21:41  来源:华体会平台官网app 作者:华体会平台下载 

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

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

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

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

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

  和单体架构不同,微服务架构是由一系列职责单一的细粒度服务构成的 分布式网状结构,服务之间通过轻量机制进行通信,这时候必然引入一个 服务注册发现 问题,也就是说服务提供方要将自己的服务地址注册到某个地方(服务注册中心, 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 来做。

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

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

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

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

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

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

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

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

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

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

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

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

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

  在开发 / 测试环境上,程序包已经被打包成 Docker 镜像,如果能将通过测试的镜像直接推到生产环境,可以直接省去为生产环境而重复进行的打包部署工作,岂不是很美?

  如果需要达到这个效果,就需要将程序包打包成具有环境无关性,也就是说,在程序包里是不可以有环境相关的配置信息的,这也就引入了 配置中心 组件。

  使用配置中心还有一个很重要的附加价值,那就是可以做到不同环境的配置信息可以由不同的人来管理,加强了生产环境的配置信息的安全性,例如数据库帐号和密码。

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

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

  所以,为了让运维的同学能生活得踏实点,最好也能把监控平台给建了。如果希望快速搭建监控平台,可以考虑 Nagios,Zabbix。如果希望扩展性、可定制性更好,可以考虑使用以下组件搭建:

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

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

  在这篇文章结束的时候,我们可以回过头来看看,我们只需要在开发层面理解了注册中心、服务发现、负载均衡、服务网关和管理端集成框架,在运维层面准备好持续集成工具、配置中心和监控告警工具,就可以很容易地落地微服务架构,享受微服务架构带来的精彩。云坤祝大家玩得愉快。返回搜狐,查看更多