手记

漫谈微服务

最近发现谈论微服务的人越来越多。不仅是互联网公司或者传统软件公司,不少甲方公司也在说微服务。关于微服务的原理和实现方法,网上到处都能找到资料。但我想当一个概念被炒的太热的时候,作为圈内人士,倒是应该以冷静的视角来做一些不一样的思考了。下面的一些想法仅作一家之言,欢迎吐槽。

关于单体式应用
每个谈论微服务的文章都会先提一下与之相对的单体式应用。作为一个12年前就参与大型商业软件的开发的人来说,单体式应用实在是太正常不过的东西了。是的,我们写软件的时候会划分各种模块,把相关的功能,资源拆分到不同的逻辑层的模块或者是项目里面。不管最后是打包生成到同一个二进制文件,还是生成大量不同的二进制文件,这种应用在今天看来都是不折不扣的单体式应用。哪怕是现在,很多大型的商业软件仍然是单体式应用。它们现在工作得非常好,没有任何问题。

当然,我说的这些大型商业软件,都是桌面软件。

还有一件事需要强调的就是,是不是单体式应用和代码层面上做的模块划分没有关系,都9012年了,难道还有成熟的软件不做模块划分么?

微服务架构的提出
稍微了解过微服务架构的人,也都知道,微服务这个东西本身没有任何技术创新。这个概念在十年二十年以前就可以提出,没有任何技术上的难点。但我们大概也能想到,微服务在近些年才火起来,肯定有它的道理。

在我看来,硬要说的话,可能就是移动互联网的发展,3G,4G以及将来的5G的发展,带来了对微服务架构的强烈需求。

正因为互联网和移动互联网的高速发展,导致大量的软件产品以互联网应用的方式产生。而互联网应用和传统的桌面应用有一个很大的区别,就是桌面应用的交付太简单了。只要把光盘或者是安装包交付给最后的使用者,用户怎么用软件就和软件制造商没什么关系了。但是对互联网应用来说,软件制造商(或者说服务提供商)需要持续维护线上运行的应用。互联网公司是有足够的动力,希望能降低运维成本,降低软件更新的风险,提高线上服务器资源的使用效率。

所以说,谁最需要使用微服务架构,谁推微服务架构最积极?互联网公司!你一传统软件公司或者甲方公司凑什么热闹!:)

互联网应用运维的难点
运行一个在线应用实在是太操心了。因为可能会导致这个在线应用出问题的点实在是太多了。

这个应用跑在托管的服务器还是云虚拟机上?服务器或者是虚拟机会不会出问题?带宽有没有保证?服务器会不会受到攻击? 更难以保证的是,应用本身会不会出问题,某个组件会不会挂掉,应用升级更新的时候如何保证服务持续工作,如何使得影响面最小,如果版本更新有问题,如何回滚。

如果是一个桌面应用,crash了就重启,一个客户crash和其他客户没关系。但是一个互联网应用秒秒钟几十万上下的用户,停服务一分钟都是钱。

所以对于互联网应用来说,最重要的原则只有一个:穷尽单点。

穷尽单点
所谓的穷尽单点,也就是不要让你的在线服务在部署层面上有任何一个单点存在。也就是在任何一个可以独立部署的点都有备份,如果对应的网站,webapi,数据库等“服务”挂掉或者是更新,都有备份顶上,或者马上就能监控到并重启对应的服务。这才算的上是穷尽了单点。而单点的消灭才意味着这个互联网应用处于一个高可用的状态。

保持互联网应用的高可用状态,是互联网应用运维的核心诉求,而这个核心诉求反过来影响到了开发层面的架构设计和选型。

因此,如果微服务架构和部署无关,那是耍流氓,而如果现在还抱着传统的软件部署和开发架构无关的思想,那就更是耍流氓了。

如果使用单体互联网应用
要知道,穷尽单点这个事,并不必然意味着微服务。很简单的道理,单体应用没办法穷尽单点吗?用多台服务器部署,做负载均衡,后台数据库做成高可用集群,是不是可以穷尽单点了?

微服务这个事更多的是从经济学的角度来说的。

我们前面也说过,单体应用也有模块划分,但是模块和模块的使用频率,重要程度,更新的频繁程度都是不一样的。对于单体应用来说,其穷尽单点的方式,或者是对它做多备份的方式必然是整个应用整体做负载均衡,这样就带来几个问题。

更新单体应用的时候,必须整个应用更新,更新的时间长。
更新单体应用的时候,如果想要保持应用不下线,只能把其中整个应用的一个个备份单独切下来更新,如果之前做了两个应用实例的负载,那么在更新过程中,整个应用的性能就减少了平时的1/2,如果做了三个应用的负载,那么就是减少1/3。某个应用的模块挂掉,意味着这个富贵论坛实例挂掉。性能同样减少了平时的1/2或者1/3。
如果我们发现某个模块的调用频率很高,需要增加服务器资源,只能针对整个单体应用增加资源。
所以我说,为什么使用微服务,或者说为什么互联网应用不用单体应用,是从经济学角度来说的。

微服务的好与坏
微服务意味着把一个大的单体应用拆分成可以独立部署的服务。针对这一个个独立的服务,我们可以单独对其做负载均衡;可以单独部署在相同或者不同的服务器上;可以只更新其中的一个服务而不影响其他,这样在更新的过程中,损失的只是其中的一点点性能;而更新和回滚的速度也会快的多,这些都是互联网产品之所以采用微服务的原因。

但正是因为我们把一个单体应用拆分成了多个独立部署的服务,由此也带来了一系列的问题:

开发的复杂性增加,开发一个单体应用是最省事的,微服务架构下不同的服务之间的调度本身就是一个需要处理的问题。
部署的难度增加,可以想象是部署一个单独的网站省事,还是部署一系列的网站省事。
版本发布,回滚需要有专门的工具。单个网站就手动发布也没事,几十个网站还用手动发布那就是自己找麻烦了。Docker和K8s,该你们上场了!(这个以后再专门介绍)
性能,可靠性监控也需要一系列的工具。Zabbix们也有了用武之地。
据说人类进化的原则就是:凑合着用,不行的话先解决当前的问题,再找各种办法解决这个解决方案带来的其他问题。软件技术的进步看起来也是同样的原则。

谁应该怎么用微服务
回到最开始的话题,虽然说软件行业的从业人员都应该对新技术敏感。但是在公司层面,更应该考虑的是公司的成本和利益。

因此,传统的桌面应用软件公司是否应该考虑微服务的使用,我倒真是持保留意见。而对于甲方公司,关心所使用的产品是否使用微服务架构,不如制定明确的产品验收标准,包括产品可靠性和性能在内的一系列指标。 而对于互联网公司的互联网产品,如果仅仅只是使用了一些微服务的框架来做开发,却并没有体现在部署层面,那就很幽默了。

之所以这么说,是因为最近还真的接触到一些很有趣的现象,稍微吐吐槽吧。 计划在将来的分享里面也加入上面提到的一些技术的介绍。

题外话,关于互联网技术的发展对行业的影响
互联网技术的发展对很多行业和技术的发展的作用,很多人都这个感觉,但又没办法完全理清楚。这个话题如果展开那肯定是一个超大的话题,我们简单的说几个例子。

我们就说最重要的,互联网和移动互联网网速的提升,以及用户电脑和手机性能的提升。这两个提升直接导致在线应用成为可能。 因为网速和性能的提升,使得我们可以在网络上实时传递大量的影音数据,大量数据样本的收集成为了可能,而计算性能的提升也使得我们能实时的对用户的输入做计算和反馈,这才使得人工智能相关的技术的应用在近些年有爆发式增长。大量数据的沉淀也给大数据相关的应用和开发提供了数据基础。

在线游戏也是同样的道理,十几年前我们就在网吧玩三角洲吃鸡了,但只有最近几年才能在手机上玩,为什么?因为最近几年手机的网速和手机性能才达到了在线吃鸡的要求。

比较悲剧的是VR,其实我一直觉得VR技术一定会在将来的某个时刻又一次彻底改变人类的生活方式,但是为什么直到现在VR还是那么不温不火,原因其实也很简单,基础硬件技术没有达到要求。人类的大脑和人眼实在是太精密了,有一点点的延迟,卡顿,就受不了。在计算能力还没有能够欺骗人脑人眼之前,VR设备以及相关的软件应用还需要等待。

0人推荐
随时随地看视频
慕课网APP