縷一縷集群、分布式、微服務等概念，
參考地址：https://www.cnblogs.com/howtobuildjenkins/p/8999441.html
系統框架，分為以下幾種：
1、單機架構
這種架構，很常見，比如有一個很小的系統，不用處理很多東西，只需要一台服務器，在上面搭建出自己需要的服務，就可以開始工作。
這種架構優點顯而易見，方便維護，出了問題解決起來很方便。
缺點也很明顯，如果處理變多，資源也就不夠用了。
集群是個物理形態，分布式是個工作方式。
只要是一堆機器，就可以叫集群，他們是不是一起協作着干活，這個誰也不知道；一個程序或系統，只要運行在不同的機器上，就可以叫分布式；
2、集群架構（每台服務器上的代碼及服務一樣）
單機架構無法滿足要求，集群架構就可以提供更好更快的處理，簡單來說，集群架構就是把單機架構上面運行的服務，摘出來，然后復制，在多個服務器上面進行部署，這樣可以提高工作效率。在集群中，每個服務器都稱為節點，每個節點提供不同的服務，比如Database、Web、日志工具。
集群搭建出來后，有這樣一個角色，負責調度客戶端來的請求究竟要到哪一台服務器上去，然后在進行接下來的工作流，這個角色叫做——“負載均衡器”
集群也分為高可用集群，負載均衡集群（可能高並發架構就是負載均衡架構的升級版）。
高可用集群工具常見的有：heartbeat，pacemaker，keepalived
負載均衡器工具常見的有：nginx，lvs，HAproxy
集群架構優點：可擴展性，服務器資源不夠用，就可以加一台繼續進行工作
缺點：維護起來困難，trouble shoot的時候需要花費時間較多
3、負載均衡
負載均衡（Load Balance）其意思就是分攤到多個操作單元上進行執行，從而共同完成工作任務；
按軟硬件分：
軟件負載均衡解決方案是指在一台或多台服務器相應的操作系統上安裝一個或多個附加軟件來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求；
硬件負載均衡解決方案是直接在服務器和外部網絡間安裝負載均衡設備，這種設備通常稱之為負載均衡器，由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求；
按本地全局分：
本地負載均衡是指對本地的服務器群做負載均衡，全局負載均衡是指對分別放置在不同的地理位置、有不同網絡結構的服務器群間作負載均衡；
負載均衡有三種部署方式：路由模式、橋接模式、服務直接返回模式。路由模式部署靈活，約60%的用戶采用這種方式部署；橋接模式不改變現有的網絡架構；服務直接返回（DSR）比較適合吞吐量大特別是內容分發的網絡應用。約30%的用戶采用這種模式；
采用負載均衡模式時候，要實時檢查多台服務器的存活狀態：
默認的健康檢查方式是Ping檢查服務器的存活狀態。只有服務器狀態為Up時，負載均衡器才會把會話分發給該服務器處理，從而最大可能性的保障用戶的請求得到服務器的正常應答，這也是負載均衡器的基本功能之一；
4、分布式系統（由一組通過網絡進行通信、為了完成共同的任務而協調工作的計算機節點組成的系統）
分布式系統的出現是為了用廉價的、普通的機器完成單個計算機無法完成的計算、存儲任務。其目的是利用更多的機器，處理更多的數據；
我的理解就是 1+1 > 2 ;
只有當單個節點的處理能力無法滿足日益增長的計算、存儲任務的時候，且硬件的提升（加內存、加磁盤、使用更好的CPU）高昂到得不償失的時候，應用程序也不能進一步優化的時候，我們才需要考慮分布式系統；
因為，分布式系統要解決的問題本身就是和單機系統一樣的，而由於分布式系統多節點、通過網絡通信的拓撲結構（拓撲結構是指網絡中各個站點相互連接的形式），會引入很多單機系統沒有的問題，為了解決這些問題又會引入更多的機制、協議，帶來更多的問題；
分布式和微服務區別：
分布式部署的應用不一定是微服務架構的，比如集群部署，它是把相同應用復制到不同服務器上，但是邏輯功能上還是單體應用。
即分布式系統可以是集群部署也可以是微服務架構；
5、微服務架構（每個高內聚的業務模塊為一個服務，單獨部署一個子系統）
先來對前面的知識點做個總結。 從單機結構到集群結構，你的代碼基本無需要作任何修改，你要做的僅僅是多部署幾台服務器，（集群）每台服務器上運行相同的代碼就行了。但是，當你要從集群結構演進到微服務結構的時候，之前的那套代碼就需要發生較大的改動了。所以對於新系統我們建議，系統設計之初就采用微服務架構，這樣后期運維的成本更低。但如果一套老系統需要升級成微服務結構的話，那就得對代碼大動干戈了。所以，對於老系統而言，究竟是繼續保持集群模式，還是升級成微服務架構，這需要你們的架構師深思熟慮、權衡投入產出比。
下面開始介紹所謂的微服務。 微服務就是將一個完整的系統，按照業務功能，拆分成一個個獨立的子系統，在微服務結構中，每個子系統就被稱為“服務”。這些子系統能夠獨立運行在web容器中，它們之間通過RPC方式通信。
簡單來說微服務就是很小的服務，小到一個服務只對應一個單一的功能，只做一件事。這個服務可以單獨部署運行，服務之間可以通過RPC來相互交互，每個微服務都是由獨立的小團隊開發，測試，部署，上線，負責它的整個生命周期。
微服務架構優點：
耦合度大大降低，可以獨立開發、獨立部署、獨立測試，效率高；
耦合度降低，系統更易於擴展；
某些公用的服務的復用性更高：
6、RPC通信是什么？
RPC（Remote Procedure Call Procotol）遠程過程調用協議，通俗的解釋就是：客戶端在不知道調用細節的情況下，調用存在於遠程計算機上的某個對象，就像調用本地應用程序中的對象一樣。阿里巴巴的Dubbo框架，就是運用RPC協議比較好的框架；
舉個例子，假設需要開發一個在線商城。按照微服務的思想，我們需要按照功能模塊拆分成多個獨立的服務，如：用戶服務、產品服務、訂單服務、后台管理服務、數據分析服務等等。這一個個服務都是一個個獨立的項目，可以獨立運行。如果服務之間有依賴關系，那么通過RPC方式調用
7、Dubbo
Dubbo是一套微服務系統的協調者，在它這套體系中，一共有三種角色，分別是：服務提供者（下面簡稱提供者）、服務消費者（下面簡稱消費者）、注冊中心。
Dubbo是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動注冊和發現；可以和 Spring框架無縫集成
你在使用的時候需要將Dubbo的jar包引入到你的項目中，也就是每個服務都要引入Dubbo的jar包。然后當這些服務初始化的時候，Dubbo就會將當前系統需要發布的服務、以及當前系統的IP和端口號發送給注冊中心，注冊中心便會將其記錄下來。這就是服務發布的過程。與此同時，也是在系統初始化的時候，Dubbo還會掃描一下當前系統所需要引用的服務，然后向注冊中心請求這些服務所在的IP和端口號。接下來系統就可以正常運行了。當系統A需要調用系統B的服務的時候，A就會與B建立起一條RPC信道，然后再調用B系統上相應的服務。
這，就是Dubbo的作用。
8、微服務具體部署
當我們使用了微服務架構后，我們將一個原本完整的系統，按照業務邏輯拆分成一個個可獨立運行的子系統。為了降低系統間的耦合度，我們希望這些子系統能夠運行在獨立的環境中，這些環境之間能夠相互隔離。
在Docker出現之前，若使用虛擬機來實現運行環境的相互隔離的話成本較高，虛擬機會消耗較多的計算機硬件/軟件資源。Docker不僅能夠實現運行環境的隔離，而且能極大程度的節約計算機資源，它成為一種輕量級的“虛擬機”。
Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然后發布到任何流行的Linux機器上，也可以實現虛擬化，容器是完全使用沙箱機制，相互之間不會有任何接口。
當我們使用微服務架構后，隨着業務的逐漸發展，系統之間的依賴關系會日益復雜，而且各個模塊的構建順序都有所講究。對於一個小型系統來說，也許只有幾個模塊，那么你每次采用人肉構建的方式也許並不感覺麻煩。但隨着系統業務的發展，你的系統之間的依賴關系日益復雜，子系統也逐漸增多，每次構建一下你都要非常小心謹慎，稍有不慎整個服務都無法正常啟動。而且這些構建的工作很low，但卻需要消耗大量的精力，這無疑降低了開發的效率。不過沒關系，Jenkins就是來幫助你解決這個問題的。
Jenkins是一個開源軟件項目，是基於Java開發的一種持續集成工具，用於監控持續重復的工作，旨在提供一個開放易用的軟件平台，使軟件的持續集成變成可能；
我們只需在Jenkins中配置好代碼倉庫、各個模塊的構建順序和構建命令，在以后的構建中，只需要點擊“立即構建”按鈕，Jenkins就會自動到你的代碼倉庫中拉取最新的代碼，然后根據你事先配置的構建命令進行構建，最后發布到指定的容器中運行。你也可以讓Jenkins定時檢查代碼倉庫版本的變化，一旦發現變動就自動地開始構建過程，並且讓Jenkins在構建成功后給你發一封郵件。這樣你連“立即構建”的按鈕也不需要按，就能全自動地完成這一切構建過程。