简介

微服务是最近几年比较热的一个话题,并且随着容器技术(docker, k8s等)的不断发展只会越来越热,同时也有各种各样的大中小公司尝试着拥抱微服务构架。先不管这种做法是否正确,但在这种情势下,作为一个后台程序员,如果你不了解一下微服务,是会被人笑话的。

那什么是微服务?

很多介绍微服务的定义的,都会引用Martin Fowler的定义: Microservices。按Martin Fowler的定义,微服务构架是一系列可独立部署的服务,没有明确的定义,围绕业务能力,自动化部署,终端智能化,分布式语言和数据。简而言之,单一的应用程序由一系列的微小的服务组成,微小服务运行在自己的进程内并通过轻量级的机制(如REST, RPC等)通讯,这些微小服务围绕业务能力,自动化独立部署,可以有少量集中化管理的机制协调这些服务,微小服务可以使用不同语言和不同的数据存储技术。

盗用Martin Fowler文章中的图(出处: https://martinfowler.com/articles/microservices/images/sketch.png):

什么是微服务

以前的构架有什么不好的地方?

很多介绍微服务的文章,都喜欢和单体程序做比较,当作为一名后台程序员,印象中极少公司是单体程序,大多都根据业务功能进行模块划分(比如,用户管理模块,订单模块,库存模块,出入金模块等等),模块又可能包括多个应用程序协调运行。这样的构架相对于微服务有什么不好的地方?模块的划分,虽然可以使复杂的业务得到分解,但相对于“微”来说还是巨大的单体,而且随着业务的发展,软件复杂度与之相应增强,而且不够弹性,比如搞活动是订单模块超忙,用户管理模块却相对空闲。

个人认为,微服务以前模块划分,SOA等方式发展而来,克服旧构架可能存在的问题,它以明确或通用的构架的方式明确怎么去构架一个良好的系统。微服务就是为了解决软件的复杂性和弹性的问题,微服务,它更易于理解,使团队专注于自己的业务,独立开发、发布、管理微服务,独立部署、扩展和管理,彼此隔离,复用现有服务,在现有服务基础上构建全新的功能。

听起来微服务很爽,是不是都需要使用这种新的构架模式呢?每一个看过构架的书籍,都看过这样一样话,构架是根据业务发展而来的,不能为了技术而技术。用不用”微服务“需要个人觉得需要根据自身业务情况而决定。因为”微服务“的构架模式需要新的基础框,同时也带来新的问题,如果业务不是过于复杂,在原有构架很好适应的情况下,盲目拥护微服务的代价并不一定高于收益。

服务注册、发现和健康检查

由于微服务构架将应用划分为一系列的细粒度的单一职责的服务,所以系统内存在N多的服务组成的服务网(Service mesh),这些服务通过轻量级的通讯机制进行联通,N多服务构成网状的结构。在这种情况下必定会引入服务注册发现的概念,当服务启动起来的时候,必须有一个地方宣告,我能提供什么样的服务,同时调用者也能感知到有多少个服务的提供者。通常提供这些功能的,是由一个去中心化的分布式注册中心框架完成,常见的如: zookeeper, etcd, consul, Eureka等等。

任何一个程序都可能存在bug,服务可能存在挂掉,假死,慢,忙等各种情况,服务调用者需要知道服务是否可用,甚至是否过载等情况,以确定是否调用该服务,所以服务需要健康检查。健康检查一般两方面做,一个在服务向注册中心注册时,告知服务TTL,同时服务在TTL时间内每隔一段时间进行一次重新注册,类似于心跳报文;另外一方面,在注册中心内部对注册上来的服务运用各种手段进行检测,比如telnet端口,http访问特定连接,运行特定检查脚本等。

实施微服务,需要要增加的是注册中心群集,必须熟悉注册中心的运维(安全,权限等),同时应用开发者也必须熟悉注册中心的注册和发现等api使用。

consul注册中心例:

consul注册中心实例

配置中心

由于微服务构架服务的数量众多,每个服务对应的机器使用一套配置文件的方式是不太现实的,由此又引用一个概念,分布式配置中心。配置中心框架,使服务统一从一个中心读取配置文件,同时能够感知到配置的变化从而进行服务的重新初始化。更有甚者,配置中心还支持灰度发布,分环境、分集群管理配置,完善的权限、审核机制等等。目前开源的配置中心也是比较多,比如disconf, ctrip apollo等。

当然,一般上面的注册中心也是提供简单的键值存储,如果要求不是很高,也是可以用做简单的配置中心,当然也是可以开发一个配置中心的RPC服务。

实施微服务,需要增加配置中心群集,必须熟悉配置中心的运维(安全,权限等),同时应用开发者也必须熟悉配置中心配置获取,配置的变化感知等。

consul配置中心例:

consul配置中心实例

服务网关和负载均衡

将内部服务暴露于外的组件,称之为服务网关。服务网关最重要的功能是将外部的请求路由到内部的服务,除此之外,网关通常还具备鉴权(请求鉴权中心或自己是鉴权中心),反爬虫,限流容错,监控等功能。通常我们需要在服务网关框架上,根据自己业务需求进行进一步开发。这里只是介绍概念,这里描述的很简单,事实上服务网关对外提供唯一的出口,实现起来可能很复杂。

无论是服务网关调用后端的服务,或是内部服务调用后端服务,都涉及调用哪个服务的问题,即是负载均衡,通常是实现方式是在客户端上实现,一般有现成框架,在其基础上进行扩展。当然实现方式是多样的,也有不少把请求丢到消息队列,事件总线等。不管实现方式如何,目标是服务的负载需要均衡。

其他

  • 降级,熔断,限流 一个前端请求一般会依赖于多个后端服务,突发流量可能造成单个服务延迟致雪崩效应,如何限流,降级,熔断?
  • 监控链路跟踪和日志收集 一个业务分布于多个服务的调用之中,如何追踪调用链路?日志又如何收集,如ELK栈?
  • 快速部署扩容缩容 docker/k8s/istio快速部署?
  • 分布式事务 分布式事务是微服务经常遇到的问题也是比较困难的问题,使用网上说的复杂的2PC,TCC等,还是简单的补偿??

小结

本来想每个部分都简单写写,列一下常用的方式,做法是什么。但是很多东西自己都只是有一个概念,并没有认真的去实践,没有经过自己实践过的东西也不知道写什么,倒是网上却又很多的介绍,总结的都挺好。每一部分都有N多的解决方案,直接参考网上搜索结果即可。

由上,微服务架构需要掌握的东西和概念很多,能否在原来业务上转为微服务,或在新业务上使用微服务?熟练了为服务的模式,会不会开展业务更舒畅?或许是,也或许不是,因为并没有尝试过,不过倒是很乐意去尝试一下。

微服务尝试: stock