从传统BS架构的⾓度看微服务架构
先假定⼀个条件：所有数据库、中间件和web server都是收费的，没有免费开源版，⽐如mysql，redis都是收费的，也是收费的。这个条件下会对架构设计产⽣什么影响？
从技术总监或CTO的⾓度来说，为了降低购买license的成本，合理的选择就是购买尽量少的license，在硬件上投资，提升单台server 的运算和存储能⼒，⽽且为了充分挖掘硬件的性能，不可能使⽤或容器技术。这就是传统的⼤型机时代的思维定式。从组织体系来看，就是⼀开发和运维⼈员围绕⼀台巨⼤机器转，想⽅设法把这个机器伺候好。这个时候，机器上的软件和数据的复杂度会越来越⾼，各种系统⾼度耦合在⼀起。微服务？请恕⾂妾⽆能。如果硬要采⽤微服务，第⼀个问题就是license费从哪⾥来。
上⾯的假设，也就是传统B/S架构设计者⾯临的限制条件。因⽽，在那个时代，oracle sql sever配合NAS和SAN，恨不得⼲脆搞个IBM ⼩型机装数据库。这也是那时候主流⽹站，包括淘宝、新浪的架构。我所在的公司，易车，也是如此。也曾经考虑过LAMP，但是考察了mysql 的功能就放弃了：不⽀持事务，没有存储过程，数据库⽂件还可能坏掉。
mysql被oracle收购后，innodb引擎逐渐成熟，到了这个时候，mysql才逐渐进⼊主流⽹站的视线。
mysql的功能逐渐能够跟sql server oracle相匹敌后，开源和免费就成了杀⼿锏。同时，因为apache tom
cat都是免费的，完全可以⼀个功能搞⼀套web+DB，这个就是。并且让开发⼈员负责⾃⼰的微服务，避免两个⼈同时负责同⼀个微服务，实现了责任到⼈，便于管理和考核。微服务的另⼀个好处就是：原来⼀个⼤数据库负载很⾼，现在分散到多个DB，⾃然⽽然就把负载分散了。更进⼀步，可以在负载不⾼的时候，就预先进⾏拆分，为以后的⾼负载做准备，但是刚开始不可能⼀台机器⼀个服务，太浪费硬件，如果⼀台机器⼏个服务，配置起来⼜容易出错，这种情况下，容器就发挥作⽤了。从成本的⾓度考虑，为了提升单台服务器的利⽤率，就需要部署尽量多的服务，但是负载上来了，⼜要⽅便的把服务迁移到其他机器上，只有⽤容器和容器平台，才能做到。
如果运维⼈员，需要管理⼏百、上千台服务器，没有容器技术，简直不可想象。让运维⼈员去配置redis  mysql，⽐较难，毕竟不是开发⼈员，很难了解软件的版本变化和配置的细节。只有当运维只⾯对容器的时候，才可能管理上千台服务器，上万个服务。对于运维⼈员来说，容器就是集装箱，不关⼼⾥⾯的货物，只要cpu 内存没有超过阈值就ok，如果超过了就迁移，甚⾄迁移都可以写脚本⾃动进⾏。
再做⼀个类⽐，当初短信收费的时候，每次写短信都尽量把字数⽤⾜，减少发短信的次数，不会发⼀个短信只是包含⼀个笑脸。反之，随着互联⽹技术的发展，IM的兴起，发送信息是免费的，⾃然没⼈关⼼发⼀次iM只发⼀个笑脸的性价⽐了。
mysql下载免费版总结⼀下，微服务的兴起，其根源在于开源软件的发展，软件都免费了，mysql 被oracle改造的可以跟sql server媲美了，⾃然就可以放⼿使⽤。⼀个功能⼀个DB变为常态，既能让开发⼈员责任清晰，⼜能把系统横向拆分⽀撑更⼤的负载。⾃然形成了微服务。微服务多了，管理就成了课题，为了解决⼏千上万的微服务管理，就诞⽣了容器技术。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。