从传统B/S架构的角度看微服务架构

先假定一个条件：所有数据库、中间件和web server都是收费的，没有免费开源版，比如mysql，redis都是收费的，nginx也是收费的。这个条件下会对架构设计产生什么影响？

    从技术总监或CTO的角度来说，为了降低购买license的成本，合理的选择就是购买尽量少的license，在硬件上投资，提升单台server的运算和存储能力，而且为了充分挖掘硬件的性能，不可能使用虚拟机或容器技术。这就是传统的大型机时代的思维定式。从组织体系来看，就是一群开发和运维人员围绕一台巨大机器转，想方设法把这个机器伺候好。这个时候，机器上的软件和数据的复杂度会越来越高，各种系统高度耦合在一起。微服务？请恕臣妾无能。如果硬要采用微服务，第一个问题就是license费从哪里来。

   上面的假设，也就是传统B/S架构设计者面临的限制条件。因而，在那个时代，oracle sql sever配合NAS和SAN，恨不得干脆搞个IBM小型机装数据库。这也是那时候主流网站，包括淘宝、新浪的架构。我所在的公司，易车，也是如此。也曾经考虑过LAMP，但是考察了mysql 的功能就放弃了：不支持事务，没有存储过程，数据库文件还可能坏掉。

   mysql被oracle收购后，innodb引擎逐渐成熟，到了这个时候，mysql才逐渐进入主流网站的视线。

   mysql的功能逐渐能够跟sql server oracle相匹敌后，开源和免费就成了杀手锏。同时，因为apache tomcat都是免费的，完全可以一个功能搞一套web+DB，这个就是微服务。并且让开发人员负责自己的微服务，避免两个人同时负责同一个微服务，实现了责任到人，便于管理和考核。微服务的另一个好处就是：原来一个大数据库负载很高，现在分散到多个DB，自然而然就把负载分散了。更进一步，可以在负载不高的时候，就预先进行拆分，为以后的高负载做准备，但是刚开始不可能一台机器一个服务，太浪费硬件，如果一台机器几个服务，配置起来又容易出错，这种情况下，容器就发挥作用了。从成本的角度考虑，为了提升单台服务器的利用率，就需要部署尽量多的服务，但是负载上来了，又要方便的把服务迁移到其他机器上，只有用容器和容器平台，才能做到。

   如果运维人员，需要管理几百、上千台服务器，没有容器技术，简直不可想象。让运维人员去配置redis  mysql，比较难，毕竟不是开发人员，很难了解软件的版本变化和配置的细节。只有当运维只面对容器的时候，才可能管理上千台服务器，上万个服务。对于运维人员来说，容器就是集装箱，不关心里面的货物，只要cpu 内存没有超过阈值就ok，如果超过了就迁移，甚至迁移都可以写脚本自动进行。

  再做一个类比，当初短信收费的时候，每次写短信都尽量把字数用足，减少发短信的次数，不会发一个短信只是包含一个笑脸。反之，随着互联网技术的发展，IM的兴起，发送信息是免费的，自然没人关心发一次iM只发一个笑脸的性价比了。

  总结一下，微服务的兴起，其根源在于开源软件的发展，软件都免费了，mysql 被oracle改造的可以跟sql server媲美了，自然就可以放手使用。一个功能一个DB变为常态，既能让开发人员责任清晰，又能把系统横向拆分支撑更大的负载。自然形成了微服务。微服务多了，管理就成了课题，为了解决几千上万的微服务管理，就诞生了容器技术。