前端如何理解服务部署的发展历程

目录

• 前言
• 历史

内容

前言

早期我更多只是接触CVM去部署项目，这其中更多关注的其实只能算是一个单体demo。但现实情况是生成环境中我们的项目部署往往需要考虑它的健康度，稳定性，抗压以及容灾等诸多问题。于是，这块技术也在不断的发展进步，一个一个的被验证并投入生产实践。作为一个关注前端发展的开发者，除了特别喜欢留意前端的新趋势，对于周边的这些内容也同样感兴趣，因为总觉得多关注一些，往往能够帮助我们更容易拓宽视野，打开思路，有助于我们更好的解决问题，更全面的思考应对。于是我希望能用前端的视野来介绍下关于这块的一些知识点。

历史

1. 单机

   这是我们最先开始的服务部署方案，我们可能先只是考虑能部署在互联网，让人能访问到而已。算是一个单机版把。

   但是我们可能会从程序自身想办法有保障业务的多可用，那就是多进程，一个服务会提供多个进程，以应对客户端的请求和运算要求。

   但它的极限也就是这台机器。于是人们开始考虑组合多台机器。

2. 集群

   多台机器组合在一起，模式也是可以多种多样的。我们可能最熟知的就是主从关系，即master集群和业务集群，master负责专门负责集群的运作消耗，业务集群就专注接受master调配和业务部署的消耗。

   业务集群内的机器节点互相合作，按照服务当前请求量与压力值，动态调节其中的节点数目，以满足访问量级较大的业务需要。

3. docker

   集群的出现后，我们虽然有应对大负荷量级服务的应对方案，但还是有些场景是有一些问题的。例如， 资源利用率问题。 业务部署要么就共用机器资源，部署在了一起；要么就只能基于节点为最小单位，组合某几台专门服务某个业务；这其中的资源利用率是有限的。部署受到现场部署环境的影响较大。往往服务的部署都会受制于主机系统，主机系统之间多多少少有差别，这对于部署和问题排查来说都是不利的。

   于是docker技术开始产生。它就是将常规的系统资源，以容器为单位进行切割，每个容器可以独立，容器内是一个独立的系统镜像，它们的部署就像工业流水线上批量生产一样方便。不论宿主机环境的差异，一旦宿主机上提供了docker服务之后，我们就可以运行一个个容器，容器内的系统镜像我们也可以提前做好，部署就只是执行命令的事了。容器有自己的端口，它与宿主机之间可以通过端口映射，这样就能做到容器内服务端口的暴露。这就好像我们写Js插件时会实现一些必要的私有方法，但其中只有部分是需要暴露的接口，这样暴露出来的方法才会被使用插件的人所调用，而私有方法则不需要暴露。到这一步，我们似乎容器之间还是独立的，缺少多个容器之间联系和整体资源的伸缩编排的控制。所以K8S出现了。

4. K8S

   K8S它就像是一个集装箱，将容器有效的管理起来。它会提供一系列针对其中容器的编排规则，涵盖了网络，配置，路由，服务发现，资源控制，命名空间，集群，资源隔离，镜像控制，系统监控，日志等等，方方面面的内容来巩固我们的容器服务。

   其实有些类似的方案是一个叫做docker swarm的，Docker Swarm是Docker自己的Docker容器本地集群解决方案，具有与Docker生态系统紧密集成并使用自己的API的优势。它监视跨服务器群集的容器数量，是在没有其他硬件的情况下创建群集docker应用程序的最便捷方式。它为Dockerized应用程序提供了一个小规模但有用的编排系统。

   如果你是需要成熟的部署和监控选项， 需要快速可靠的响应时间，需要开发复杂的应用程序，并且需要高资源计算而不受限制，那还是考虑k8s。