最近发现谈论微服务的人越来越多。不仅是互联网公司或者传统软件公司，不少甲方公司也在说微服务。关于微服务的原理和实现方法，网上到处都能找到资料。但我想当一个概念被炒的太热的时候，作为圈内人士，倒是应该以冷静的视角来做一些不一样的思考了。下面的一些想法仅作一家之言，欢迎吐槽。
关于单体式应用
每个谈论微服务的文章都会先提一下与之相对的单体式应用。作为一个12年前就参与大型商业软件的开发的人来说，单体式应用实在是太正常不过的东西了。是的，我们写软件的时候会划分各种模块，把相关的功能，资源拆分到不同的逻辑层的模块或者是项目里面。不管最后是打包生成到同一个二进制文件，还是生成大量不同的二进制文件，这种应用在今天看来都是不折不扣的单体式应用。哪怕是现在，很多大型的商业软件仍然是单体式应用。它们现在工作得非常好，没有任何问题。
当然，我说的这些大型商业软件，都是桌面软件。
还有一件事需要强调的就是，是不是单体式应用和代码层面上做的模块划分没有关系，都9012年了，难道还有成熟的软件不做模块划分么？
微服务架构的提出
稍微了解过微服务架构的人，也都知道，微服务这个东西本身没有任何技术创新。这个概念在十年二十年以前就可以提出，没有任何技术上的难点。但我们大概也能想到，微服务在近些年才火起来，肯定有它的道理。
在我看来，硬要说的话，可能就是移动互联网的发展，3G，4G以及将来的5G的发展，带来了对微服务架构的强烈需求。
正因为互联网和移动互联网的高速发展，导致大量的软件产品以互联网应用的方式产生。而互联网应用和传统的桌面应用有一个很大的区别，就是桌面应用的交付太简单了。只要把光盘或者是安装包交付给最后的使用者，用户怎么用软件就和软件制造商没什么关系了。但是对互联网应用来说，软件制造商（或者说服务提供商）需要持续维护线上运行的应用。互联网公司是有足够的动力，希望能降低运维成本，降低软件更新的风险，提高线上服务器资源的使用效率。
所以说，谁最需要使用微服务架构，谁推微服务架构最积极？互联网公司！你一传统软件公司或者甲方公司凑什么热闹！：）
互联网应用运维的难点
运行一个在线应用实在是太操心了。因为可能会导致这个在线应用出问题的点实在是太多了。
这个应用跑在托管的服务器还是云虚拟机上？服务器或者是虚拟机会不会出问题？带宽有没有保证？服务器会不会受到攻击？
更难以保证的是，应用本身会不会出问题，某个组件会不会挂掉，应用升级更新的时候如何保证服务持续工作，如何使得影响面最小，如果版本更新有问题，如何回滚。
如果是一个桌面应用，crash了就重启，一个客户crash和其他客户没关系。但是一个互联网应用秒秒钟几十万上下的用户，停服务一分钟都是钱。
所以对于互联网应用来说，最重要的原则只有一个：穷尽单点。
穷尽单点
所谓的穷尽单点，也就是不要让你的在线服务在部署层面上有任何一个单点存在。也就是在任何一个可以独立部署的点都有备份，如果对应的网站，webapi，数据库等“服务”挂掉或者是更新，都有备份顶上，或者马上就能监控到并重启对应的服务。这才算的上是穷尽了单点。而单点的消灭才意味着这个互联网应用处于一个高可用的状态。
保持互联网应用的高可用状态，是互联网应用运维的核心诉求，而这个核心诉求反过来影响到了开发层面的架构设计和选型。
因此，如果微服务架构和部署无关，那是耍流氓，而如果现在还抱着传统的软件部署和开发架构无关的思想，那就更是耍流氓了。
如果使用单体互联网应用
要知道，穷尽单点这个事，并不必然意味着微服务。很简单的道理，单体应用没办法穷尽单点吗？用多台服务器部署，做负载均衡，后台数据库做成高可用集群，是不是可以穷尽单点了？
微服务这个事更多的是从经济学的角度来说的。
我们前面也说过，单体应用也有模块划分，但是模块和模块的使用频率，重要程度，更新的频繁程度都是不一样的。对于单体应用来说，其穷尽单点的方式，或者是对它做多备份的方式必然是整个应用整体做负载均衡，这样就带来几个问题。
- 更新单体应用的时候，必须整个应用更新，更新的时间长。
- 更新单体应用的时候，如果想要保持应用不下线，只能把其中整个应用的一个个备份单独切下来更新，如果之前做了两个应用实例的负载，那么在更新过程中，整个应用的性能就减少了平时的1/2，如果做了三个应用的负载，那么就是减少1/3。某个应用的模块挂掉，意味着这个实例挂掉。性能同样减少了平时的1/2或者1/3。
- 如果我们发现某个模块的调用频率很高，需要增加服务器资源，只能针对整个单体应用增加资源。
所以我说，为什么使用微服务，或者说为什么互联网应用不用单体应用，是从经济学角度来说的。
微服务的好与坏
微服务意味着把一个大的单体应用拆分成可以独立部署的服务。针对这一个个独立的服务，我们可以单独对其做负载均衡；可以单独部署在相同或者不同的服务器上；可以只更新其中的一个服务而不影响其他，这样在更新的过程中，损失的只是其中的一点点性能；而更新和回滚的速度也会快的多，这些都是互联网产品之所以采用微服务的原因。
但正是因为我们把一个单体应用拆分成了多个独立部署的服务，由此也带来了一系列的问题：
- 开发的复杂性增加，开发一个单体应用是最省事的，微服务架构下不同的服务之间的调度本身就是一个需要处理的问题。
- 部署的难度增加，可以想象是部署一个单独的网站省事，还是部署一系列的网站省事。
- 版本发布，回滚需要有专门的工具。单个网站就手动发布也没事，几十个网站还用手动发布那就是自己找麻烦了。Docker和K8s，该你们上场了！（这个以后再专门介绍）
- 性能，可靠性监控也需要一系列的工具。Zabbix们也有了用武之地。
据说人类进化的原则就是：凑合着用，不行的话先解决当前的问题，再找各种办法解决这个解决方案带来的其他问题。软件技术的进步看起来也是同样的原则。
谁应该怎么用微服务
回到最开始的话题，虽然说软件行业的从业人员都应该对新技术敏感。但是在公司层面，更应该考虑的是公司的成本和利益。因此，传统的桌面应用软件公司是否应该考虑微服务的使用，我倒真是持保留意见。而对于甲方公司，关心所使用的产品是否使用微服务架构，不如制定明确的产品验收标准，包括产品可靠性和性能在内的一系列指标。
而对于互联网公司的互联网产品，如果仅仅只是使用了一些微服务的框架来做开发，却并没有体现在部署层面，那就很幽默了。
之所以这么说，是因为最近还真的接触到一些很有趣的现象，稍微吐吐槽吧。
计划在将来的分享里面也加入上面提到的一些技术的介绍。
题外话，关于互联网技术的发展对行业的影响
互联网技术的发展对很多行业和技术的发展的作用，很多人都这个感觉，但又没办法完全理清楚。这个话题如果展开那肯定是一个超大的话题，我们简单的说几个例子。
我们就说最重要的，互联网和移动互联网网速的提升，以及用户电脑和手机性能的提升。这两个提升直接导致在线应用成为可能。
因为网速和性能的提升，使得我们可以在网络上实时传递大量的影音数据，大量数据样本的收集成为了可能，而计算性能的提升也使得我们能实时的对用户的输入做计算和反馈，这才使得人工智能相关的技术的应用在近些年有爆发式增长。大量数据的沉淀也给大数据相关的应用和开发提供了数据基础。在线游戏也是同样的道理，十几年前我们就在网吧玩三角洲吃鸡了，但只有最近几年才能在手机上玩，为什么？因为最近几年手机的网速和手机性能才达到了在线吃鸡的要求。
比较悲剧的是VR，其实我一直觉得VR技术一定会在将来的某个时刻又一次彻底改变人类的生活方式，但是为什么直到现在VR还是那么不温不火，原因其实也很简单，基础硬件技术没有达到要求。人类的大脑和人眼实在是太精密了，有一点点的延迟，卡顿，就受不了。在计算能力还没有能够欺骗人脑人眼之前，VR设备以及相关的软件应用还需要等待。