前后端部署在两台服务器服务器配置要求_线上环境部署概览

点击上方“Java知音”&＃xff0c;选择“置顶公众号”

技术文章第一时间送达&＃xff01;

作者&＃xff1a;等你归去来

cnblogs.com/yougewe/p/10327217.html

推荐阅读(点击即可跳转阅读)

1. SpringBoot内容聚合

2. 面试题内容聚合

3. 设计模式内容聚合

4. 排序算法内容聚合

5. 多线程内容聚合

谈到线上环境&＃xff0c;一般开发同学&＃xff0c;不太容易接触到。即使接触到&＃xff0c;也只是其中的冰山一角&＃xff01;

所以&＃xff0c;其实说起线上环境的部署&＃xff0c;咱们好像都有点懂&＃xff0c;但是又都不一定完全懂&＃xff01;网上的知识无穷无尽&＃xff0c;但往往都是各司一职&＃xff0c;对于普通同学&＃xff0c;很难窥其全貌&＃xff01;

所以&＃xff0c;我今天就来说说&＃xff0c;一些普通的线上环境的部署步骤&＃xff0c;和一些脚本小技巧吧。只希望通过这篇文章&＃xff0c;能够让大家有一个运维的全局观&＃xff01;

我将会分几条线来整理咱们的运维思路&＃xff01;

一、从理论上讲&＃xff0c;我们应该怎么做&＃xff1f;

1.针对的是什么样的用户群体&＃xff0c;体量大概会有多少&＃xff1f;

这是一个部署规划的前题。为啥呢&＃xff1f;

一、如果你针对的是后台管理员&＃xff0c;人数也不多&＃xff0c;那么你可能只需要一个服务器就可以了&＃xff0c;前后端也都可以部署在同一台服务器上&＃xff1b;如果稍微考虑下单点故障问题&＃xff0c;则顶多两台服务器搞定&＃xff01;

二、如果针对的是前端普通用户&＃xff0c;那么&＃xff0c;往往就会考虑多机部署&＃xff0c;前后端分离&＃xff0c;单点问题&＃xff0c;负载均衡了&＃xff1b;至于具体要部署多少台&＃xff0c;则要根据你的用户情况来定了&＃xff0c;当然&＃xff0c;前期一般没必要部署很多台服务器&＃xff01;更多的考虑是横向扩展的能力。只要能支持横向扩展&＃xff0c;则短期内&＃xff0c;往往不用担心性能和架构问题&＃xff01;

2.为支持预估的用户量&＃xff0c;大概需要多少的带宽&＃xff1f;
有访问就会有流量产生&＃xff0c;而预估的用户量&＃xff0c;则是一个带宽资源需求的一个决断依据&＃xff01;

一般针对前期用户不太确定的场景&＃xff0c;可以先买个 10M 左右的共享带宽&＃xff0c;基本能够应付&＃xff1b;经过一段时间的观察后&＃xff0c;再进行带宽的变更也可以&＃xff1b;

当然&＃xff0c;考虑带宽&＃xff0c;自然也会存在一个公网IP的问题&＃xff0c;因为流量是从IP进来的。而在IP之前&＃xff0c;则是域名的访问。域名问题则又涉及到DNS&＃xff0c;不必细说&＃xff01;

公网IP可以是直接指向机器的&＃xff0c;也可以是指向负载均衡器的。如果想要支持横向扩展&＃xff0c;则IP的指向一定是一个负载均衡器。因为只有这样&＃xff0c;当遇到流量突增&＃xff0c;或者做活动的时候&＃xff0c;才能更快速的进行扩容&＃xff01;

3.数据库规划如何&＃xff1f;

数据在当下时代&＃xff0c;算是重中之重了。机器没了可以再买&＃xff0c;代码没了可以再写&＃xff0c;但是数据没了就完蛋了&＃xff01;

数据库一般要遵从几个基本原则: 一、带宽要大&＃xff1b;二、运算速度要快&＃xff1b;三、要能承受足够大的运算空间&＃xff1b;(即&＃xff1a;带宽足够大/cpu核数够多/内存容量够大/最大并发连接数/…)

所以&＃xff0c;一般不要在数据库上省钱&＃xff0c;能多点就多点&＃xff01;

另外&＃xff0c;也不要什么样的数据都往数据库(关系型数据库)存&＃xff0c;搞清楚各类型数据库的强项与弱项&＃xff0c;做出明智的选择。否则会带来很多不必要的麻烦&＃xff01;

4.应用要基于操作系统来部署还是基于容器来部署&＃xff1f;

这是个决策性的问题&＃xff01;基于操作系统的部署&＃xff0c;是一种比较传统和常见的部署方式。优点是&＃xff0c;很多系统工具都是完善的&＃xff0c;只要你大概知道要部署什么&＃xff0c;部署下来一般不会有太多问题&＃xff0c;因为这是个完整的系统。

但是&＃xff0c;由于系统与系统之间可能不能完全一致&＃xff0c;有各种各样的差异&＃xff0c;所以&＃xff0c;你在这个机器上运行成功的东西&＃xff0c;在另外的机器上则不一定能成功。因此&＃xff0c;基于系统的部署将会使我们的问题排查难度大大增加&＃xff0c;而且移值性会很差。比如你在机器A上安装了10个软件&＃xff0c;你可能配置了n个选项&＃xff0c;但是&＃xff0c;当你在安装B机器的时候&＃xff0c;你并不能很好的利用原有的配置&＃xff0c;你还得从头一个个地来&＃xff01;

因此&＃xff0c;有另一个部署方案&＃xff0c;基于容器的部署(我这里是基于docker容器的部署)。docker就类似于一个个的虚拟机&＃xff0c;但是它更加轻量级&＃xff0c;当一个docker部署好后&＃xff0c;你可以任意复制到其他机器上运行&＃xff0c;看起来很诱人吧。

不过&＃xff0c;docker只是入门级容器&＃xff0c;对于大量集群容器的管理&＃xff0c;还是显得力不从心&＃xff0c;当然你很容易找到另一个方案: Kubernetes (K8s); 你只要花上少许的时间了解下&＃xff0c;你就可以应用了&＃xff01;

当然了&＃xff0c;使用容器的方案&＃xff0c;有没有什么缺点呢&＃xff1f;应该是有的&＃xff0c;比如本来可以基于系统的监控方案&＃xff0c;因为接入容器后&＃xff0c;监控指标则不一定适用了&＃xff0c;当然现成的方案还是有的&＃xff0c;不过得另外再花点时间研究了。再比如&＃xff1a;如果容器出了问题&＃xff0c;是否能排查出来&＃xff0c;这也是另一个问题&＃xff01;

5.都有些什么样的基础设施或者中间件&＃xff1f;

想要运行应用程序&＃xff0c;自然是先考虑运行环境的。比如&＃xff1a;应用需要 nginx 来做http服务器&＃xff0c;用 tomcat 来做java web应用服务器&＃xff0c;用redis来做缓存中间件&＃xff0c;用zk来做应用协调中间件&＃xff0c;用rabbitmq来做消息中间件&＃xff0c;等等&＃xff01;

因此&＃xff0c;要在代码跑起来之前&＃xff0c;先要把这些环境给准备好咯。

准备这些中间件或基础设施之前&＃xff0c;也要问下当下的形势&＃xff0c;是否有高性能高可用应用需求&＃xff1f;比如&＃xff1a;是否需要集群部署&＃xff0c;或者单机部署&＃xff1f;往往集群部署又会依赖其他的中间件&＃xff01;也更复杂&＃xff01;

当然&＃xff0c;这些都不是事。事儿是在出问题之后&＃xff0c;能够有意识&＃xff0c;能够猜测到问题发生的点&＃xff01;

6.应用代码应该怎样部署&＃xff1f;

当基础环境就绪后&＃xff0c;就应该让主角上场了。应用代码怎么部署&＃xff1f;

最简单的: 通过ftp上传代码到服务器上后&＃xff0c;一个个部署&＃xff01;这种方案是最原始的&＃xff0c;也是在没有办法搞更好的方案的时候使用的&＃xff0c;不应长期使用&＃xff1b;

稍微好点的: 使用集成工具(如jenkins)进行打包&＃xff0c;然后上传一个私有yum镜像服务器(yum 源)。然后在线进行yum 安装&＃xff1b;这种方式&＃xff0c;借助了集成工具&＃xff0c;几个好处:

• 可以检测代码合法性如&＃xff1a;单元测试、代码规范(可能需要插件)&＃xff1b;

• 对任何的改动有简单留档&＃xff0c;可以备查的同时&＃xff0c;也为代码的回滚提供了可能&＃xff1b;

• 减少了手动上传导致的包破坏的可能性&＃xff1b;

• 适合大规模应用&＃xff1b;

再成熟点的: 再往后面&＃xff0c;手动 yum 安装也已经太累了&＃xff0c;所以急需一个部署平台&＃xff0c;实现自动化部署&＃xff1b;(这里的自动化部署可能就是基于CI集成部署的一种升级版)。总之&＃xff0c;大大减小了人工参与程序&＃xff0c;提升了效率&＃xff0c;同时也保证了质量&＃xff01;当然&＃xff0c;这种部署平台已经经过了严格的测试&＃xff0c;出错的可能性也比较小了&＃xff01;

7.服务器的安全性&＃xff1f;

不考虑服务器的安全性的应用&＃xff0c;无异于自暴自弃。黑客无处不在&＃xff0c;不过幸好现在系统也是越来越完善&＃xff0c;只要稍加控制&＃xff0c;即不那么容易被攻破了。但是如果放弃安全防护&＃xff0c;则随便来一个菜鸟程序员就把你搞死了&＃xff0c;那时的损失就大了。

网络安全是个很专业的领域&＃xff0c;我不敢造次去谈它。不过我们可以简单的做下防护: 如防火墙、授权操作、病毒库等等。当然&＃xff0c;如果使用xx云服务&＃xff0c;则轻松方便多了&＃xff0c;在后台点点设置几下搞定&＃xff01;

8.服务的可监控性&＃xff1f;

无监控&＃xff0c;不上线&＃xff01;

这是一个警示&＃xff0c;如果线上服务没有监控&＃xff0c;则所有线上的东西&＃xff0c;都成了盲区&＃xff0c;这对程序员GG们来说&＃xff0c;简直太糟糕了&＃xff0c;虽然他们很自信&＃xff01;

监控分两个方面&＃xff1a;一是系统级别的监控&＃xff1b;二是应用级别的监控&＃xff1b;(一般忽略其他监控: 如网络)

系统级别的监控一般可以安装第三方的软件来解决: 如 zabbix, grafana …

而应用级别的监控&＃xff0c;则需要自己拥有一套监控代码了&＃xff0c;而这对初期项目&＃xff0c;则往往比较吃力。当然&＃xff0c;如果引入一些开源的解决方案也是可以的&＃xff0c;比如 ELK, 做到分布式日志中心的作用的同时&＃xff0c;也可以根据日志做相应的应用报错监控&＃xff01;然而这又涉及另外的机器费用和人力成本问题&＃xff0c;也显得不那么简单了。

而如果使用xx云服务&＃xff0c;则往往都会自带服务器监控的&＃xff0c;可以很方便地查看到服务器情况&＃xff0c;站在高层次预估应用是否存在潜藏的问题&＃xff01;

如上&＃xff0c;就是一些个人觉得的在部署一整套线上环境的时候&＃xff0c;需要考虑的事项&＃xff01;从理论上讲解了下个人见解&＃xff0c;不对之处&＃xff0c;请赐教&＃xff01;

二、接下来&＃xff0c;我将给到一些实际的操作捷径或提示&＃xff1f;(linux)

1.免密登录服务器&＃xff1f;

在n服务器之间跳转&＃xff0c;如果每次都要求输入密码&＃xff0c;那确实太烦了。尤其在密码一般还很不容易记住的情况下&＃xff01;

所以&＃xff0c;可以将一台服务器作为跳板机&＃xff0c;在这台服务器上&＃xff0c;可以免密地登录到允许的n台子服务器&＃xff1b;

操作步骤有二&＃xff1a;

# 1. 先使用 ssh-keygen 生成本机的key

2.服务器之间文件(夹)拷贝&＃xff1f;

拷贝文件的目的有很多&＃xff0c;比如&＃xff1a;代码同步&＃xff0c;文件同步&＃xff0c;资源同步&＃xff0c;甚至是会话同步….

# 1. 使用scp 拷贝文件

其中&＃xff0c;scp一般是系统自带的命令&＃xff0c;而rsync则需要自行安装服务。

scp复制你可以认为是增量复制&＃xff0c;所以远程文件往往会越来越大&＃xff0c;垃圾文件越来越多。

而rsync则是保持两端完全一致&＃xff0c;可能会符合应用场景&＃xff01;但是&＃xff0c;别忘了把rsync服务加入到开机启动项中&＃xff01;

3.快捷使用 ssh 等等命令&＃xff0c;使用 tab 键进行信息补全&＃xff1f;

当使用 ssh / scp 等等命令操作的时候&＃xff0c;其操作对象往往 1.2.3.x 这样的ip显示&＃xff0c;如果不能友好点&＃xff0c;那确实太累了&＃xff01;我们可以如下操作&＃xff0c;以实现 ssh 也能更好的记忆&＃xff1a;

# 在文件 /root/.bashrc 中&＃xff0c;添加脚本如下&＃xff0c;使自动补全添加 ssh

如上补全工作&＃xff0c;无需在所有服务器上进行操作&＃xff0c;只需在相应的跳板机上提供功能即可&＃xff01;

4.简要 saltstack 搭建指南&＃xff1f;

salt 是个方便易用的集群管理工具&＃xff0c;比如你可以用于批量重启服务&＃xff0c;全局搜索日志等等&＃xff1b;

# 1. 安装, 仅需到相应机器上安装即可

5.简要集群复制shell脚本&＃xff1f;

有时&＃xff0c;你可能需要将你的应用发布到n台服务中&＃xff0c;你可以直接改如下shell,也可以依赖于salt这样的高级工具进行发布&＃xff01;shell 参考如下&＃xff1a;

#!/bin/bash

6.简要docker搭建指南&＃xff1f;

docker 作为一个容器化的基石&＃xff0c;一出世就被追棒。包括现在的 k8s &＃xff0c;也是基于docker的。docker 可以让你在一处搭建&＃xff0c;处处运行&＃xff0c;从而避免每次新买机器就要搞很久的尴尬局面&＃xff1b;其搭建也是很简单的(简单应用)&＃xff1a;

为方便任意发挥&＃xff0c;我们可以基于centos这种系统级别的镜像进行创建自己的image;

# docker 安装:

7.定制你的登录欢迎语&＃xff1f;

由于可能存在线上环境与测试环境共存的情况&＃xff0c;一不小心的切换错误&＃xff0c;就可能导致不可挽回的损失。所以&＃xff0c;如果我们能在登录的时候&＃xff0c;做一个简单的提示&＃xff0c;那么就会少一点出错的可能性。所以&＃xff0c;订制你的登录欢迎语吧&＃xff01;

# 修改登录欢迎语 vim /etc/motd

这样&＃xff0c;用户登录后&＃xff0c;就会清楚的知道自己是在操作生产环境了&＃xff01;

8.更方便的查看nginx的访问日志&＃xff1f;

对于后端的日志而言&＃xff0c;往往都是主动打印到某个固定位置&＃xff0c;从而开发人员可以直接使用 tail -f xxx.log 进行日志的查看&＃xff01;

然而对于前端的代码而言&＃xff0c;则往往没有相应的开发日志&＃xff0c;唯一可以借助的就是 http 服务器的日志来排查问题了&＃xff01;

所以&＃xff0c;比如使用 nginx 作为 http 服务器&＃xff0c;那么就应该把尽可能多的有用日志打印出来。那么&＃xff0c;如何快速查看 nginx 日志&＃xff0c;则是有必要的&＃xff01;比如我们可以这样&＃xff1a;

# vim /usr/bin/log_nginx_host , 使用 log_nginx_host 直接查看所有 nginx 日志

如上&＃xff0c;将会把访问日志与错误日志一起打印出来&＃xff0c;从而快速定位问题&＃xff01;

推荐阅读(点击即可跳转阅读)

1. SpringBoot内容聚合

2. 面试题内容聚合

3. 设计模式内容聚合

4. 排序算法内容聚合

5. 多线程内容聚合

6. 7个IntelliJ IDEA必备插件&＃xff0c;提高编码效率

7. IntelliJ IDEA 从入门到上瘾教程&＃xff0c;2019图文版&＃xff01;

看完本文有收获&＃xff1f;请转发分享给更多人