簡要的線上環境部署概覽這樣，用戶登陸後，就會清楚的知道本身是在操做生產環境了！

　　

1、從理論上講，咱們應該怎麼作？

---

1. 針對的是什麼樣的用戶羣體，體量大概會有多少？

　　這是一個部署規劃的前題。爲啥呢？

　　1、若是你針對的是後臺管理員，人數也很少，那麼你可能只須要一個服務器就能夠了，先後端也均可以部署在同一臺服務器上；若是稍微考慮下單點故障問題，則頂多兩臺服務器搞定！

　　2、若是針對的是前端普通用戶，那麼，每每就會考慮多機部署，先後端分離，單點問題，負載均衡了；至於具體要部署多少臺，則要根據你的用戶狀況來定了，固然，前期通常不必部署不少臺服務器！更多的考慮是橫向擴展的能力。只要能支持橫向擴展，則短時間內，每每不用擔憂性能和架構問題！

2. 爲支持預估的用戶量，大概須要多少的帶寬？

　　有訪問就會有流量產生，而預估的用戶量，則是一個帶寬資源需求的一個決斷依據！

　　通常針對前期用戶不太肯定的場景，能夠先買個 10M 左右的共享帶寬，基本可以應付；通過一段時間的觀察後，再進行帶寬的變動也能夠；

　　固然，考慮帶寬，天然也會存在一個公網IP的問題，由於流量是從IP進來的。

　　而在IP以前，則是域名的訪問。域名問題則又涉及到DNS，沒必要細說！

　　公網IP能夠是直接指向機器的，也能夠是指向負載均衡器的。若是想要支持橫向擴展，則IP的指向必定是一個負載均衡器。由於只有這樣，當遇到流量突增，或者作活動的時候，才能更快速的進行擴容！

3. 數據庫規劃如何？

　　數據在當下時代，算是重中之重了。機器沒了能夠再買，代碼沒了能夠再寫，可是數據沒了就完蛋了！

　　數據庫通常要聽從幾個基本原則: 1、帶寬要大； 2、運算速度要快； 3、要能承受足夠大的運算空間；（即：帶寬足夠大/cpu核數夠多/內存容量夠大/最大併發鏈接數/...）

　　因此，通常不要在數據庫上省錢，能多點就多點！

　　另外，也不要什麼樣的數據都往數據庫（關係型數據庫）存，搞清楚各種型數據庫的強項與弱項，作出明智的選擇。不然會帶來不少沒必要要的麻煩！

4. 應用要基於操做系統來部署仍是基於容器來部署？

　　這是個決策性的問題！基於操做系統的部署，是一種比較傳統和常見的部署方式。優勢是，不少系統工具都是完善的，只要你大概知道要部署什麼，部署下來通常不會有太多問題，由於這是個完整的系統。

　　可是，因爲系統與系統之間可能不能徹底一致，有各類各樣的差別，因此，你在這個機器上運行成功的東西，在另外的機器上則不必定能成功。所以，基於系統的部署將會使咱們的問題排查難度大大增長，並且移值性會不好。好比你在機器A上安裝了10個軟件，你可能配置了n個選項，可是，當你在安裝B機器的時候，你並不能很好的利用原有的配置，你還得從頭一個個地來！

　　所以，有另外一個部署方案，基於容器的部署（我這裏是基於docker容器的部署）。docker就相似於一個個的虛擬機，可是它更加輕量級，當一個docker部署好後，你能夠任意複製到其餘機器上運行，看起來很誘人吧。不過，docker只是入門級容器，對於大量集羣容器的管理，仍是顯得力不從心，固然你很容易找到另外一個方案: Kubernetes (K8s); 你只要花上少量的時間瞭解下，你就能夠應用了！固然了，使用容器的方案，有沒有什麼缺點呢？應該是有的，好比原本能夠基於系統的監控方案，由於接入容器後，監控指標則不必定適用了，固然現成的方案仍是有的，不過得另外再花點時間研究了。再好比：若是容器出了問題，是否能排查出來，這也是另外一個問題！

5. 都有些什麼樣的基礎設施或者中間件？

　　想要運行應用程序，天然是先考慮運行環境的。好比：應用須要 nginx 來作http服務器，用 tomcat 來作java web應用服務器，用redis來作緩存中間件，用zk來作應用協調中間件，用rabbitmq來作消息中間件，等等！

　　所以，要在代碼跑起來以前，先要把這些環境給準備好咯。

　　準備這些中間件或基礎設施以前，也要問下當下的形勢，是否有高性能高可用應用需求？好比：是否須要集羣部署，或者單機部署？每每集羣部署又會依賴其餘的中間件！也更復雜！
　　固然，這些都不是事。事兒是在出問題以後，可以有意識，可以猜想到問題發生的點！

6. 應用代碼應該怎樣部署？

　　當基礎環境就緒後，就應該讓主角上場了。應用代碼怎麼部署？

　　最簡單的: 經過ftp上傳代碼到服務器上後，一個個部署！這種方案是最原始的，也是在沒有辦法搞更好的方案的時候使用的，不該長期使用；

　　稍微好點的: 使用集成工具(如jenkins)進行打包，而後上傳一個私有yum鏡像服務器（yum 源）。而後在線進行yum 安裝；這種方式，藉助了集成工具，幾個好處: 

　　　　1. 能夠檢測代碼合法性如：單元測試、代碼規範（可能須要插件）；
　　　　2. 對任何的改動有簡單留檔，能夠備查的同時，也爲代碼的回滾提供了可能；
　　　　3. 減小了手動上傳致使的包破壞的可能性；
　　　　4. 適合大規模應用；

　　再成熟點的: 再日後面，手動 yum 安裝也已經太累了，因此急需一個部署平臺，實現自動化部署；（這裏的自動化部署可能就是基於CI集成部署的一種升級版）。總之，大大減少了人工參與程序，提高了效率，同時也保證了質量！固然，這種部署平臺已經通過了嚴格的測試，出錯的可能性也比較小了！

7. 服務器的安全性？

　　不考慮服務器的安全性的應用，無異於自暴自棄。黑客無處不在，不過幸虧如今系統也是愈來愈完善，只要稍加控制，即不那麼容易被攻破了。可是若是放棄安全防禦，則隨便來一個菜鳥程序員就把你搞死了，那時的損失就大了。

　　網絡安全是個很專業的領域，我不敢造次去談它。不過咱們能夠簡單的作下防禦: 如防火牆、受權操做、病毒庫等等。固然，若是使用xx雲服務，則輕鬆方便多了，在後臺點點設置幾下搞定！

8. 服務的可監控性？

　　無監控，不上線！

　　這是一個警示，若是線上服務沒有監控，則全部線上的東西，都成了盲區，這對程序員GG們來講，簡直太糟糕了，雖然他們很自信！

　　監控分兩個方面： 一是系統級別的監控；二是應用級別的監控；(通常忽略其餘監控: 如網絡)

　　系統級別的監控通常能夠安裝第三方的軟件來解決: 如 zabbix, grafana ... 

　　而應用級別的監控，則須要本身擁有一套監控代碼了，而這對初期項目，則每每比較吃力。固然，若是引入一些開源的解決方案也是能夠的，好比 ELK, 作到分佈式日誌中心的做用的同時，也能夠根據日誌作相應的應用報錯監控！然而這又涉及另外的機器費用和人力成本問題，也顯得不那麼簡單了。

　　而若是使用xx雲服務，則每每都會自帶服務器監控的，能夠很方便地查看到服務器狀況，站在高層次預估應用是否存在潛藏的問題！

 

2、接下來，我將給到一些實際的操做捷徑或提示？(linux)

---

1. 免密登陸服務器？

　　在n服務器之間跳轉，若是每次都要求輸入密碼，那確實太煩了。尤爲在密碼通常還很不容易記住的狀況下！

　　因此，能夠將一臺服務器做爲跳板機，在這臺服務器上，能夠免密地登陸到容許的n臺子服務器；

　　操做步驟有二：

# 1. 先使用 ssh-keygen 生成本機的key
ssh-keygen -t rsa            # 若是已生成不要重複生成
# 2. 使用 ssh-copy-id 將本機的 key 發送到須要免密登陸的服務器，首次copy時會要求輸入密碼，後續則免密了
ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.1.2.111

2. 服務器之間文件（夾）拷貝？

　　拷貝文件的目的有不少，好比：代碼同步，文件同步，資源同步，甚至是會話同步。。。

　　

# 1. 使用scp 拷貝文件
scp /home/ol-web.war root@xxx.com:/www/tomcat/wepapps/    # 從本機拷貝到遠程
scp /home/ol-web.war root@xxx.com:/www/tomcat/wepapps/    # 從遠程拷貝到本機
scp -r /www/nginx/html/ root@$1.2.3.2:/www/nginx/html/    # 從本機拷貝文件夾到遠程
# 2. 使用 rsync 同步文件，（可能須要安裝 rsync 服務）
rsync -av --delete /www/nginx/html/ root@$1.2.3.1:/www/nginx/html/        # 同步全部屬性，本地刪除的文件也同步遠程刪除

　　其中，scp通常是系統自帶的命令，而rsync則須要自行安裝服務。

        scp複製你能夠認爲是增量複製，因此遠程文件每每會愈來愈大，垃圾文件愈來愈多。

        而rsync則是保持兩端徹底一致，可能會符合應用場景！可是，別忘了把rsync服務加入到開機啓動項中！

3. 快捷使用 ssh 等等命令，使用 tab 鍵進行信息補全？

　　當使用 ssh / scp 等等命令操做的時候，其操做對象每每 1.2.3.x 這樣的ip顯示，若是不能友好點，那確實太累了！咱們能夠以下操做，以實現 ssh 也能更好的記憶：

# 在文件 /root/.bashrc 中，添加腳本以下，使自動補全添加 ssh
# auto complete ...
complete -W "$(echo $(grep -v '^$|#' .ssh/config | sort -u | sed 's/^ssh //'))" ssh
# 在文件 /root/.ssh/config 中，添加須要自動補全的服務器，
Host 172.2.3.5 server-api-01
Host 172.2.3.6 server-api-02
# 以上服務器名字須要在 /etc/hosts 文件中添加相應解析
# 而登陸 server時，只需， ssh server-api-01 便可

4. 簡要 saltstack 搭建指南？

　　salt 是個方便易用的集羣管理工具，好比你能夠用於批量重啓服務，全局搜索日誌等等；

# 1. 安裝, 僅需到相應機器上安裝便可
    yum install salt-master salt-minion
# 2. 配置 /etc/salt/master /etc/salt/minion, 最簡單的，只需修改 minion 配置，指向 master 的ip便可；
    #指定master，冒號後有一個空格, minion
    master: 172.1.2.22
    id: server-api-01
    user: root
# 3. 啓動全部節點, status, restart
    systemctl start salt-master        # 162機器可用
    systemctl start salt-minion
    /etc/init.d/salt-master start    # 155機器可用
    /etc/init.d/salt-minion start
# 4. 將全部salt-minion 添加到 master 集羣管理
    salt-key -A        
# 5. 登陸跳板機 api_01, 運行salt 操做，執行集羣管理工做
    salt server-api-02 cmd.run 'lsof -i:80'
    salt '*' test.ping

5. 簡要集羣複製shell腳本？

　　有時，你可能須要將你的應用發佈到n臺服務中，你能夠直接改以下shell,也能夠依賴於salt這樣的高級工具進行發佈！shell 參考以下：

#!/bin/bash
# find out my ip to exclude...
MY_MERCHINE_IP=`ifconfig eth0 |awk -F "[: ]+" '/inet addr/{print $4}'`;
MERCHINE_IP_LIST="172.1.2.7 172.1.3.4";
for m_ip in $MERCHINE_IP_LIST;
do
        if [[ $m_ip != $MY_MERCHINE_IP ]]; then
                echo "- Installing apps to mechine@${m_ip} ...";
                # install api apps
                scp /www/test/hello-1.0.0-SNAPSHOT.jar root@${m_ip}:/www/test/
                rsync -av --delete /www/html/ root@${m_ip}:/www/html/
                echo "- Install apps to merchine@${m_ip} done.";
        fi;
done;

 6. 簡要docker搭建指南？

　　docker 做爲一個容器化的基石，一出世就被追棒。包括如今的 k8s ，也是基於docker的。docker 可讓你在一處搭建，到處運行，從而避免每次新買機器就要搞好久的尷尬局面；其搭建也是很簡單的（簡單應用）：
　　爲方便任意發揮，咱們能夠基於centos這種系統級別的鏡像進行建立本身的image;

# docker 安裝:
    yum install docker
    service docker start
# 拉取 centos6 的 docker 鏡像
    docker pull centos:6
    docker images
# 構建一個 image, 建立空目錄，編輯 Dockerfile
    vim Dockerfile         # 內容可變
        FROM centos:6
        MAINTAINER oom <w@163.com>
        # move all configuration files into container

        # RUN yum install -y lsof
        # EXPOSE 80
        # CMD ["sh","-c","service httpd start;bash"]
# 建立鏡像
    docker build -t tmp_image:1.0 .      
# 建立並運行容器
    docker run -h tmp_container -itd --name tmp_container -v /opt/docker/webapps:/www/webapp tmp_image:1.0    
# 進入容器，至關於進入 centos 操做系統
    docker exec -it tmp_container bash
# 保存容器修改到images
　　docker commit -m 'web final.' 49d79fc19eaa tmp_image:1.2
# 備份容器修改後的docker鏡像 
　　docker save > /opt/images/images_final/tmp_image.final.tar tmp_image:1.2
# 恢復你的備份鏡像，即全網發佈
# 能夠在任何裝 docker 的地方加載保存的鏡像
　　docker load -i /opt/images/images_final/tmp_image.final.tar

 7. 定製你的登陸歡迎語？

　　因爲可能存在線上環境與測試環境共存的狀況，一不當心的切換錯誤，就可能致使不可挽回的損失。因此，若是咱們能在登陸的時候，作一個簡單的提示，那麼就會少一點出錯的可能性。因此，訂製你的登陸歡迎語吧！

# 修改登陸歡迎語 vim /etc/motd
*****************************************************************
!!! WARNING:  歡迎來到線上機器: service-api-01 ，請謹慎操做哦 !!!
*****************************************************************

　　這樣，用戶登陸後，就會清楚的知道本身是在操做生產環境了！

8. 更方便的查看nginx的訪問日誌？

　　對於後端的日誌而言，每每都是主動打印到某個固定位置，從而開發人員能夠直接使用 tail -f xxx.log 進行日誌的查看！

　　然而對於前端的代碼而言，則每每沒有相應的開發日誌，惟一能夠藉助的就是 http 服務器的日誌來排查問題了！

　　因此，好比使用 nginx 做爲 http 服務器，那麼就應該把儘量多的有用日誌打印出來。那麼，如何快速查看 nginx 日誌，則是有必要的！好比咱們能夠這樣：

# vim /usr/bin/log_nginx_host , 使用 log_nginx_host 直接查看全部 nginx 日誌
tail -f /var/log/nginx/access.log /var/log/nginx/error.log

　　如上，將會把訪問日誌與錯誤日誌一塊兒打印出來，從而快速定位問題！