微服务化之无状态化与容器化

此文已由作者刘超授权网易云社区发布。

欢迎访问网易云社区,了解更多网易技术产品运营经验。

 

一、为什么要做无状态化和容器化

 

很多应用拆分成微服务,是为了承载高并发,往往一个进程扛不住这么大的量,因而需要拆分成多组进程,每组进程承载特定的工作,根据并发的压力用多个副本公共承担流量。

将一个进程变成多组进程,每组进程多个副本,需要程序的修改支撑这种分布式的架构,如果架构不支持,仅仅在资源层创建多个副本是解决不了问题的。

很多人说,支撑双十一是靠堆机器,谁不会?真正经历过的会觉得,能够靠堆机器堆出来的,都不是问题,怕的是机器堆上去了,因为架构的问题,并发量仍然上不去。

阻碍单体架构变为分布式架构的关键点就在于状态的处理。如果状态全部保存在本地,无论是本地的内存,还是本地的硬盘,都会给架构的横向扩展带来瓶颈。

状态分为分发,处理,存储几个过程,如果对于一个用户的所有的信息都保存在一个进程中,则从分发阶段,就必须将这个用户分发到这个进程,否则无法对这个用户进行处理,然而当一个进程压力很大的时候,根本无法扩容,新启动的进程根本无法处理那些保存在原来进程的用户的数据,不能分担压力。

所以要讲整个架构分成两个部分,无状态部分和有状态部分,而业务逻辑的部分往往作为无状态的部分,而将状态保存在有状态的中间件中,如缓存,数据库,对象存储,大数据平台,消息队列等。

这样无状态的部分可以很容易的横向扩展,在用户分发的时候,可以很容易分发到新的进程进行处理,而状态保存到后端。而后端的中间件是有状态的,这些中间件设计之初,就考虑了扩容的时候,状态的迁移,复制,同步等机制,不用业务层关心。

如图所示,将架构分为两层,无状态和有状态。

容器和微服务是双胞胎,因为微服务会将单体应用拆分成很多小的应用,因而运维和持续集成会工作量变大,而容器技术能很好的解决这个问题。然而在微服务化之前,建议先进行容器化,在容器化之前,建议先无状态化,当整个流程容器化了,以后的微服务拆分才会水到渠成。

 

二、无状态化的几个要点

 

前面说对于任何状态,需要考虑它的分发,处理,存储。

 

对于数据的存储,主要包含几类数据:

  • 会话数据等,主要保存在内存中。

  • 结构化数据,主要是业务逻辑相关

  • 文件图片数据,比较大,往往通过CDN下发

  • 非结构化数据,例如文本,评论等

如果这些数据都保存在本地,和业务逻辑耦合在一起,就需要在数据分发的时候,将同一个用户分到同一个进程,这样就会影响架构的横向扩展。

 

 

 

对于保存在内存里的数据,例如Session,可以放在外部统一的缓存中。

 

 

 

对于业务相关的数据,则应该保存在统一的数据库中,如果性能扛不住,可以进行读写分离,如文章微服务化的数据库设计与读写分离

如果性能还是抗住不,则可以使用分布式数据库。

 

 

 

对于文件,照片之类的数据,应该存放在统一的对象存储里面,通过CDN进行预加载,如文章微服务的接入层设计与动静资源隔离

对于非结构化数据,可以存在在统一的搜索引擎里面,例如ElasticSearch。

如果所有的数据都放在外部的统一存储上,则应用就成了仅仅包含业务逻辑的无状态应用,可以进行平滑的横向扩展。

而所有的外部统一存储,无论是缓存,数据库,对象存储,搜索引擎,都有自身的分布式横向扩展机制。

 

 

在实行了无状态化之后,就可以将有状态的集群集中到一起,进行跨机房的部署,实现跨机房的高可用性。而无状态的部分可以通过Dubbo自动发现,当进程挂掉的时候,自动重启,自动修复,也可以进行多机房的部署。

 

三、幂等的接口设计

 

但是还有一个遗留的问题,就是已经分发,正在处理,但是尚未存储的数据,肯定会在内存中有一些,在进程重启的时候,数据还是会丢一些的,那这部分数据怎么办呢?

这部分就需要通过重试进行解决,当本次调用过程中失败之后,前序的进程会进行重试,例如Dubbo就有重试机制。既然重试,就需要接口是幂等的,也即同一次交易,调用两次转账1元,不能最终转走2元。

接口分为查询,插入,更新,删除等操作。

对于查询接口来讲,本身就是幂等的,不用做特殊的判断。

对于插入接口来讲,如果每一个数据都有唯一的主键,也能保证插入的唯一性,一旦不唯一,则会报错。

对于更新操作来讲,则比较复杂,分几种情况。

一种情况是同一个接口,前后调用多次的幂等性。另一种情况是同一个接口,并发环境下调用多次的正确性。

为了保持幂等性,往往要有一个幂等表,通过传入幂等参数匹配幂等表中ID的方式,保证每个操作只被执行一次,而且在实行最终一致性的时候,可以通过不断重试,保证最终接口调用的成功。

对于并发条件下,谁先调用,谁后调用,需要通过分布式锁如Redis,Zookeeper等来实现同一个时刻只有一个请求被执行,如何保证多次执行结果仍然一致呢?则往往需要通过状态机,每个状态只流转一次。还有就是乐观锁,也即分布式的CAS操作,将状态的判断、更新整合在一条语句中,可以保证状态流转的原子性。乐观锁并不保证更新一定成功,需要有对应的机制来应对更新失败。

 

四、容器的技术原理

 

 

无状态化之后,实行容器化就十分顺畅了,容器的不可改变基础设施,以及容器基于容器平台的挂掉自动重启,自动修复,都因为无状态顺畅无比。

 

关键技术一:Dockerfile

例如下面的Dockerfile。

 

 

为什么一定要用Dockerfile,而不建议通过保存镜像的方式来生成镜像呢?

这样才能实现环境配置和环境部署代码化 ,将Dockerfile维护在Git里面,有版本控制,并且通过自动化的build的过程来生成镜像,而镜像中就是环境的配置和环境的部署,要修改环境应先通过Git上面修改Dockerfile的方式进行,这就是IaC。

 

关键技术二:容器镜像

 

通过Dockerfile可以生成容器镜像,容器的镜像是分层保存,对于Dockerfile中的每一个语句,生成一层容器镜像,如此叠加,每一层都有UUID。

容器镜像可以打一个版本号,放入统一的镜像仓库。

 

 

关键技术三:容器运行时

 

 

容器运行时,是将容器镜像之上加一层可写入层,为容器运行时所看到的文件系统。

容器运行时使用了两种隔离的技术。

一种是看起来是隔离的技术,称为namespace,也即每个namespace中的应用看到的是不同的IP地址、用户空间、程号等。

 

 

另一种是用起来是隔离的技术,称为cgroup,也即明明整台机器有很多的CPU、内存,而一个应用只能用其中的一部分。

 

cgroup

 

网易云计算基础服务深度整合了 IaaS、PaaS 及容器技术,提供弹性计算、DevOps 工具链及微服务基础设施等服务,帮助企业解决 IT、架构及运维等问题,使企业更聚焦于业务,是新一代的云计算平台,点击可免费试用

 

 

 

 

相关文章:
【推荐】 MySQL MGR集群搭建