IT運維知識：什么是分布式系統

2020-03-25 16:06 作者：艾銻無限 瀏覽量：

 
談到人生中的問題，這好像是一個大話題，不過我只是想和大家分享我對人生中的這些問題的認知及領悟，又或者說在我人生中的這些問題我是對如何應對的，又有那些收獲，有句話說“以史為鑒知興衰，以人為鏡明得失”。
 
小的時候，整天玩的不意樂乎，不知道人生中還有問題，所以沒心沒肺的那段日子在記憶里好像連碎片都沒有，不知道是遺忘，還是沒有什么值得記起的事。進入學校，好像自己慢慢接觸的人越來越多，做的事也越來越多，問題好像被它們擠了出來，而且好像越擠越多。現在我總結了幾點，第一，我發現問題會隨年齡的增大而增多。第二，問題會隨你接觸的人或事越多而越多。第三，問題會隨著你能力的越大而越多。當我發現這些問題的時候，我幾乎絕望了，這可怎么辦，我這輩子都解決不完問題，而且我差點得了成長恐懼癥，都不敢學習了，這要是學多了，能力變強了，反而問題更多了，這可怎么辦？
 
三十年后，我在一次回頭看小時候的這些想法，未免有些可笑，但確實還是應證了小時候的總結，在學校只有學校問題，進入社會后又有了社會問題，找到了工作就發生了工作問題，創辦企業又有了創業問題，成了家庭又有了家庭問題，交了朋友多了朋友問題，我發現從長大到現在問題是越來越多，越來越復雜，越來越有學問。
 
難道我們這輩子就離不開問題了嗎，對，說對了，這輩子我們都要和問題在一起，我們因問題而出生，我們因問題而長大，我們因問題而學習，我們更因問題而富足，最終我們也會因問題而走向死亡。當我發現其實問題是我們一生最忠實的伙伴，它會真實的讓我們看到自己，看清自己，看透自己。更會與我們時時相伴，不離不棄。但大部分人還沒有看透問題，理解問題的時候，他們會報怨問題的發生，他們會想辦法躲避問題，他們以為自己可以逃避問題，但最終會被更多的問題所困繞。而那些往往把問題當朋友，真心與其相處，并努力去了解問題，最終穿越問題的朋友卻最終因問題成長，收獲。

   
在這里我有三個法則分享給大家,希望它們能更好的讓你應對生命中的問題:
 
第一法則:萬事萬物,陰陽兩面. 當我們看到一個問題時,也就意味著同時是生命中的一個啟示,我們把焦點放在問題上,就會越陷越深,問題就真成了問題,如果把焦點放在啟示上,就會問自己學到什么,從而會透過問題打開一個全新的開始,也許會成為我們一個起點或巧點,讓我們因問題而有所改變,因問題有所成長,因問題更得更好.
 
第二法則:循環往復,一切因果. 如果中立來看,問題只是事件呈現出來的信息,破解信息背后的譯碼,我們就能讀懂因果循環的規律,掌握規律就掌握了萬事萬物運行的根本,所以透過問題看本質,是不是感謝問題的出現.
 
第三法則:超越世相,萬法歸一.其實這個世間的相皆為幻相,就像我們看到的全息影像視頻一樣,人生的所有問題都是時間的問題,時間可以讓一切問題都不是問題,當我們不在糾結,不在把能量放在這些幻相上時,所有的問題都會自生自滅.回歸本初,用心放在當下,去體驗和享受這個世界給我們帶來的一切吧.

IT運維知識：什么是分布式系統
 
 
現在有很多Java技術方向的同學在找工作的時候會有這樣的一個要求：熟悉分布式系統理論、設計和開發，具備復雜分布式系統構建經驗。之前不少同學后臺留言問過我：這個分布式系統的設計和開發經驗，到底指的是什么？那么這篇文章就給大家來解釋一下這個問題。

1.從單系統說起

要說分布式系統是什么東西，那么就得先從單塊系統開始說起。很多同學應該都知道，如果你在一些中小型的傳統軟件公司里工作，那么很有可能現在在做的系統是如下這個樣子。所有的代碼都在一個工程里，最多可能就是通過maven等構件工具拆分了一下代碼工程模塊，不同的模塊可以放在不同的工程代碼里。在部署的時候，可能就是直接在線上的幾臺機器里直接放到里面的tomcat下來運行。然后在web服務器前面可能會有一層負載均衡服務器，比如用nginx或者是其他的負載均衡設備。很多流量很小的企業內部系統，比如OA、CRM、財務等系統，甚至可能就直接在一臺機器的tomcat下部署一下。然后直接配置一下域名解析，就可以讓這個系統的可能幾十個，或者幾百個用戶通過訪問域名來使用這個軟件了。至于說系統的依賴大概來說很可能只有一個，那就是MySQL、Oracle等關系型數據庫，可能會在某臺機器上專門部署一個數據庫，讓應用系統來使用。這種系統在很多中小型公司里現在還是比較多的，就是典型的單塊系統，所有代碼在一個工程，部署在一個tomcat里即可，這里包含了系統所有的功能。你哪怕就部署一臺機器，這個系統也可以運行，只不過為了所謂的“高可用”，可能一般會部署兩臺機器，前面加一層負載均衡設備，這樣其中一個機器掛了，另外一個機器上還有一個系統可以用。
 
2.團隊越來越大，業務越來越復雜

其實上面說的那種單系統，如果是一個10人以內的小團隊大家一起維護和開發一個用戶數量不多，請求量不大的系統，也是沒問題的，還挺方便的，對吧。你搞一個代碼倉庫，然后就一份代碼，每個人都在自己本地寫代碼，最后把代碼合并一下，做做測試，然后就直接部署基于Tomcat來就可以了。但是問題就在于說，如果你的團隊超過了10個人，比如有20個人，甚至幾十個人，上百個人要一起協作開發這個系統，然后里面的業務邏輯特別多，可能功能模塊多達幾百個。這個時候就麻煩了，你要是還用那種單塊系統的模式，那肯定是很痛苦的。因為幾十個人維護一個單系統，大家在一個工程里寫代碼，大量的沖突以及代碼合并都會讓人崩潰。而且部署的時候會有各種沖突，比如某個功能模塊要上線了，但是他必須得把整個單塊系統所有的功能都回歸測試一遍才敢上線。因為大家的代碼都在一個工程里，都是耦合在一起的，你修改了代碼，必須全部測試一遍才能保證系統正常。所以說這個時候就必須想辦法把系統改造成分布式系統了。
 
3.分布式出現：龐大系統分而治之

這個時候就可以嘗試把一個大的系統拆分為很多小的系統，甚至很多小的服務，然后幾個人組成一個小組就專門維護其中一個小系統，或者每個人維護一個小服務。簡單來說，就是分而治之，這樣每個人可以專注維護自己的代碼。
然后不同的小系統自己開發、測試和上線，都不會跟別人耦合在一起，可以自己獨立進行，非常的方便，大大簡化了大規模系統的開發成本。不同的子系統之間，就是通過接口互相來回調用，每個子系統都有自己的數據庫
 
4.分布式系統所帶來的技術問題

那么大家這個時候可以思考一下，如果你的公司是采用這種分布式系統的方式來構建公司的一個大規模系統的，那么這個時候會涉及到哪些技術問題？

（1）分布式服務框架

你如果要讓不同的子系統或者服務之間互相通信，首先必須有一套分布式服務框架。

也就是各個服務可以互相感知到對方在哪里，可以發送請求過去，可以通過HTTP或者RPC的方式。

在這里，最常見的技術就是dubbo以及spring cloud，當然大廠一般都是自己有服務框架

（2）分布式事務

一旦你的系統拆分為了多個子系統之后，那么一個貫穿全局的分布式事務應該怎么來實現？

這個你需要了解TCC、最終一致性、2PC等分布式事務的實現方案和開源技術。

（3）分布式鎖

不同的系統之間如果需要在全局加鎖獲取某個資源的鎖定，此時應該怎么來做？

畢竟大家不是在一個JVM里了，不可能用synchronized來在多個子系統之間實現鎖吧，是不是？

（4）分布式緩存

如果你原來就是個單塊系統，那么你其實是可以在單個JVM里進行本地緩存就可以了，比如搞一個HashMap來緩存一些數據。

但是現在你有很多個子系統，他們如果要共享一個緩存，你應該怎么辦？是不是需要引入Redis等緩存系統？

（5）分布式消息系統


在單塊系統內，就一個JVM進程內部，你可以用類似LinkedList之類的數據結構作為一個本地內存里的隊列。

但是多個子系統之間要進行消息隊列的傳遞呢？那是不是要引入類似RabbitMQ之類的分布式消息中間件？

（6）分布式搜索系統

如果在單塊系統內，你可以比如在本地就基于Lucene來開發一個全文檢索模塊，但是如果是分布式系統下的很多子系統，你還能直接基于Lucene嗎？

明顯不行，你需要在系統里引入一個外部的分布式搜索系統，比如Elasticsearch。

（7）其他很多的技術

比如說分布式配置中心、分布式日志中心、分布式監控告警中心、分布式會話，等等，都是分布式系統場景下你需要使用和了解的一些技術。因為沿用單塊系統時代的那些技術已經不行了，比如說你單塊系統的時候，直接在本地用一個properties文件存放自己的配置即可，日志也寫到本地即可。但
是分布式時代呢？你那么多的子系統，怎么共享同一份配置？怎么把各個系統的日志聚合寫到一個地方來查看？單系統的時候，你一個web應用直接基于Servlet API提供的Session會話功能即可，那么分布式時代呢，你有N多個子系統如果要共享會話該怎么做？

 

5.一句話總結：什么是分布式系統設計和開發經驗？

其實分析完了之后，大家應該就大概知道了，招聘上寫這個分布式系統的設計和開發經驗，其實他是一個很大的主題，里面包含很多的內容。你的系統一旦分布式了之后，通信、緩存、消息、事務、鎖、配置、日志、監控、會話，等等各種原來單塊系統場景下很容易解決的問題，都會變得很復雜，
需要引入大量外部的技術。所以你有沒有參與過類似這樣的一個大的分布式系統？你有沒有基于各種技術解決過分布式系統場景下的各種技術問題？這就是人家希望和要求的分布式系統設計和開發的經驗。如果大家還沒接觸過，建議多去學習一下。

 

6.補充說明：中間件系統及大數據系統

最后給大家說明一點，一般這種招聘如果是Java崗位要求分布式相關的經驗，其實主要還是上面說的那些東西，他面向的是分布式的業務系統的構建。但是其實分布式系統本身是一個非常復雜的話題，因為剛才說的只是一個分布式業務系統要依賴哪些技術來進行構建。但是其實比如Kafka、Rocket
等中間件，本身他也是分布式的，你要搞明白他們自己是如何實現分布式的，又是一個非常復雜的話題。此外，像hadoop、spark、hbase等大數據系統，本身也都是世界上最最復雜的分布式系統，這又涉及到大數據領域的話題了，以后有機會可以再談。