从技术演变的角度看互联网后台架构

上面这页说说，其实微服务所谓的服务发现/name service不要被忽悠觉得是多神奇的东西。最简单的Nginx/Apache这些都能做(域名转向，proxy)，或者你要写个name : address的对应关系到db里面也完全可以，再配一个定时healthcheck的服务，最简单的服务发现也就行了。

高级点用到zookeeper/etcd等等，或者SpringCloud全家桶，那只是简化配置，原理都一样。从开发角度来看，微服务的开发并不是难点，难点是微服务的配置和部署。最近一段时间微服务部署也是业界热点，除了全家桶形态的SpringCloud，也可以看看lstio这些开源工具。

上图主要大致对比一下，看看从早期的Spring到现在Spring Cloud的变化。想来用过Java Tomcat的朋友都能体会Java这一套Config based development的繁琐，开发的精力很多不是在业务代码上，往往会化不少精力去折腾配置文件。当然，Spring Cloud在这方面简化了不少，不过个人还是不太喜欢java，搞很多复杂的设计模式，封装了又封装。

这里要说并不是微服务解决一切，热门的Python Django尽管有restful-framework，但是它实际上是一个典型的Monolithic体系。对很多核心业务，其实未必要拆开成微服务。

这两者是互补关系，不是替代关系。

下面的docker我就不仔细谈了，PPT基本表达了我想表述的概念，主要意思是

- docker能够简化部署，简化开发，能够在某种程度上让开发环境和产品环境尽量接近

- 不要担心docker的性能，它不是虚拟机，可以看作在server上运行的一个process。

上图是描述docker之前开发人员的常见开发环境，首先在自己机器上装一大堆服务，像mysql, redis, tomcat啥的。也有直接在远程服务器安装环境后，多人共同登录远端开发，各自使用一个端口避免冲突…. 实际上这种土法炼钢的形态，在2019年的今天仍然在国内非常普及。

这种形态的后果就是在最后发布到生产环境时，不同开发人员会经历长时间的“联调”，各种端口、权限、脚本、环境设置在生产环境再来一遍…这也是过去运维人员的主要工作。

上一页提到的问题，并不是一定要docker来解决。在这之前，虚拟机VM的出现，以及vagrant这样的工具，都让开发环境的搭建多少轻松了一些。不过思路仍然是把VM作为一个独立服务器使用，只是因为快照、镜像和辅助工具，让环境的配置、统一和迁移更加简单快捷。

上图是对比程序运行在物理服务器、VM及docker时的资源共享情况，可以看到运行在Docker的应用，并没有比并发运行在物理服务器上占用更多资源。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!