也谈谈微服务


最近微服务的话题非常火爆,尤其是在Netflix这样的明星公司的引导下,好像现在不搞微服务就已经落后了一样,这对追求新潮技术的架构师或程序员来说,是可忍熟不可忍。因此,我也不可避免地卷入这波浪潮中,因为除了保持对新技术的关注外,同盾在系统架构发展中确实遇到了一些服务上的问题,急需一些新的思路来打破常规。

微服务(Microservices)大概最早是从Martin Fowler这哥们那里开始推广流行开的吧,我把InfoQ中国上关于微服务的大部分文章都看了一下遍,感觉和之前的SOA服务化的思想也没有本质上的不同,无非是把服务的粒度拆分的更细,之前可能很多服务都放在一个应用里提供,或者说是多个服务运行在同一个进程空间中,现在改成每个服务都有一个独立的进程空间,能够独立运行,甚至之前多个服务共享一个数据库,变成现在每个服务都有自己单独的数据库,这种方式确实带来了诸多便利,比如因为服务变得更小,更方便开发和维护,更方便独立部署,可以充分利用硬件资源,更好地隔离故障等,但是是不是放之四海而皆准呢,我觉得需要从如下几个方便考量。

业务的复杂性

如果业务相对比较简单,网站的访问量也不是很大,比如每天只有几万几十万的访问量,团队可能也就十个人不到,可能一个应用就能支撑住所有的业务,完全没有必要考虑微服务,甚至服务化可能都不需要,技术的最终目的是为了解决业务问题,不是为了炫技,能用最简单的方案解决的最好不过,就像淘宝最早就是PHP+MySQL搭的一个小网站,之后很多年也是一个大应用,包括商品、交易、支付等几乎所有的逻辑,等到业务越来越复杂,团队规模越来越大时,才不得不进行拆分,进行服务化的改造。

就是写代码一样,最开始那就那么几行代码,有必要考虑什么模块化吗,可能一个方法就搞定了,等到越来越复杂时,为了可维护性,才需要按不同功能把代码放到不同的方法中,将一个类拆成多个类,把一个模块拆成多个模块,微服务也是一样的道理。

性能

服务化之后必定带来性能的损耗,网络间的通讯必定比不过内存间的通讯,如果你的业务对性能的要求不是特别高,为了维护方便可能需要对服务进行拆分,但如果性能要求特别高,甚至可能要反其道而行之,比如我们的服务中调用到一个Geoip的基础服务,从架构上看,应该做服务调用,但是为了提升性能,我们将该服务组件嵌入到主应用里,减少网络开销。

成本

目前流行的虚拟化方式是Xen或KVM,在一台物理机上虚出多个机器来,每个虚拟机跑一个单独的应用,像我们线上就是用的KVM,一般是一虚六,如果微服务化了,那就意味着最好每个虚拟机只部署一个服务,但这样从成本的角度来看,可能不是很划算,还不如把多个服务放在一个应用里,部署到一台机器上合算,并且也完全能满足性能等方面的要求。

但是随着Docker这种轻量级的虚拟化方案的流行,给我们带来了新的机会,它能够以非常低的资源占用率来启动一个应用,一台物理机上能部署几十上百个容器,这样成本就能低到足以让我们能够接受。

基础平台

这个也是很多人可能会忽略的问题,微服务是很好,但是这是需要非常多的基础平台支撑的。

比如要使用Docker,要一个能够完善的容器管理平台,得知道目前哪个物理机上还有资源,可以让我正式放得下一个微服务,并且要有服务注册和发现的平台,让服务的消费方能马上知道你的服务地址。如果是对外暴露的服务,你得有一个API网关,能够及时地知道有哪些服务是可用的,分布在哪些位置,要有健康检查的机制,自动限流的机制等。

再比如服务多了,监控也是个大问题,如果之前你用的是像Zabbix这样的开源监控框架,每次增加一台机器都要做模板的配置,那就很痛苦了,你得必须有一套自动注册的机制,得让监控系统知道这个应用集群中有哪些机器或容器,这些机器都IP地址和端口是多少,因为如果容器化了,每次部署IP和端口都可能会变化,不过也听到Mesosphere的哥们说他们开发了一套IP自动跟随的技术,每次启动一个容器都可以动态给他分配相同的IP地址,不过目前应该还没有普及。

只有这些基础设施完备了,才能在上面方便地进行服务的构建和扩展,因此还是要根据自己的业务实际情况,量体裁衣,不可什么流行就一哄而上。

yikebocai /

Published under (CC) BY-NC-SA in categories tech  tagged with