互联网系统运营部署，维护

Posted 2021-01-24 xiaoxuebiye

    本人不是专职的运维人员， 本文将自己理解的运维技术知识做个梳理。以便

自己记忆和回顾。 

    现在的 互联网系统是越来越复杂，而且要求系统  7x24 小时不阶段的运作。 

对于大型的互联网公司，系统更是错综复杂。 越复杂的系统，越要求简单的耦合，

能够最小化的切分。 统一输入输出， 这样系统才能做的庞大，而不显的复杂。而

且需要能够方便的水平的扩容。

   一般系统架构都是随着业务，慢慢的迭代，不断重新架构适应扩张。按照我的理解

是农村的小路不要按照单向 4 车道来修。 而作为江浙沪的高速， 就不能按照单向 2

车道的标准来修。  

    不同的业务要求，配置不同系统架构， 也就需要不同的运维技术。  因此，首先要

明白系统需求，对系统需求进行分类梳理。

    系统分类：         
         静态门户网站         
         企业内部MIS系统         
        简单的新闻/blog/商城系统

        复杂的新闻/blog/商城系统

         千万/亿级的应用 


一个静态网站，维护很简单。   一般公司委托外面公司设计，开发，部署，一条龙服务。
顺带需要买个域名，买点空间。 放置在阿里云/腾讯云上。 一般静态网页不会出现访问问题。
不多废话。

到了企业内部的MIS系统， 一般企业都会有网管负责。这里说的企业的MIS系统包括 OA，
进销存，ERP， 信息化业务系统。   轻量一点， 就是一个数据库 + 一个web服务器。有时候
会放在一台机器上。  运维人员做的事，也就是保证服务器不宕机，数据库及应用服务程序，
启动关闭， 最重要的是不能让数据丢失。  这一层面，可能更多的工作量。 是教其它业务人
员，怎么使用使用系统。     随着业务的增加， 数据的安全要求会提升到一个高度，因为一次
数据故障的恢复，就会让整个业务上产生不小的影响。  因此， 磁盘的存储形式，会从单机向
阵列， 向云方式转变。 数据库会做主从，以便快速恢复。  web服务器 会从单台转变为多台
用负载均衡来平衡。 

企业内部的MIS系统， 一般不会不会放在外网和云上。 原因有两点：1 历史传承， 2 数据安全。
比如一个商场的收银系统， 比如一个生产型企业的 进销存系统。 这些数据如果放在云上，多少
有些不放心， 他们会基于原先的服务器，扩建为机房，统一管理。  可以放置企业内部网络设备。
服务器组，支持企业的信息化运作。   他们可能会采用  EXSI 这些技术来实现硬件虚拟化，能
够快速的提供虚拟服务器，支撑业务的扩展和收缩。 医院，学校，政府等这些行业，事业都会
用到这些技术。   网络规划，机房规划管理 也是他们运维的重要工作之一。

 

再说互联网， 一般互联网系统无非分：前端界面（面向用户）， 后台管理（面向内部管理人员），
接口服务层（面向前端和后台管理），数据库。 这四个层面。

到了移动互联网后，就是：app 或 微信公众号（小程序）， 后台管理，接口服务层，数据库。

运维的工作内容主要是申请云服务器，部署各个应用。搭建系统监控，确保这4个部分能够7x24
小时运作， 如果出现故障，最短的时间发现， 最短时间修复。  根据业务需要不断迭代升级前端，
接口服务层。  

面向的东西主要是：
各种 js 框架，   .net  ； 比如  React ，  jq  等等。
服务器： tomcat ,  jboss,  nginx,   apache  , 
基础语言环境： node.js   ,  python . java .   net  等
数据库：  mysql, oracle,  mongo,  redis 等

运维的工作不会涉及开发， 但是需要了解  对应项目实现的语言实现的运行环境。 从而能够进行
部署，维护（启动，关闭，升级）。
运维需要了解 各种web服务器的配置项   都是做什么用， 怎么配置这些参数来确保  web服务器的性能。
运维需要了解 各种数据库的安装， 启动， 关闭。 数据备份。   规模大的企业 有独立的数据库管理员做。 

这个级别的应用， 负载均衡，集群的需求会冒出来， 只要量一上来，就需要做这些事情。 


如果有了一定的业务量， 各种应用，包括前端和接入层（web api） . 均会逐渐采用  docker  方式。因为
docker 方式，部署第二台新机器； 不需要安装 软件运行环境，只需要更新代码。  这样，部署，扩容一台
新服务器，仅仅需要几分钟的事情。     几个应用装在一台机器上， 也就 一个机器 多个  docker 的事情。 
很清晰明了，便于管理；  而一个实例机器装 直接几个应用，这种方式 就显得很复杂。 

再随着业务的增加， 会用到  k8   , swarm    +  docker hub 这种部署方式， 这两种技术是面向集群（服务）
的部署方式。   先创建集群（把一组主机捆绑在一起），  再创建服务，一个服务即一个应用，可以是 ui,  也
可以是api , 也可以是 socket ,  而这个服务后面 是多个  docker 容器组成的负载均衡。   

这样就可以很轻松的实现扩容和缩减（几秒内）， 还可以用自动化脚本动态的去管理缩减和扩容。
到了这个程度， 基本上公司的业务 在飞速发展。       主要的工作量 就是写很多的脚本， 准备很多的 docker file   .


千万级，亿级的系统， 均是由于业务量的暴增， 最频繁的，最瓶颈的业务不得以拆分出来。 用一些缓存技术，
确保业务低延时。  多了中间层，  业务 垂直拆分。  导致系统，层次增加， 垂直系统增加。 而运维，面临的

更多的是管理问题。 管理系统的架构， 也管理运维的团队。  而技术无非以上这些。