系統結構的發展以及為什麼要使用分布式系統
本人認識分布式系統是從微服務開始接觸的，所有分布式的知識都是以微服務視角來描述和理解。其中涉及到的技術主要以spring cloud為主。能力有限，難免會有疏漏。歡迎各位指正和交流。
a. 傳統的單體服務
在傳統網際網路專案中，我們往往以乙個專案的形式進行開發。在專案中通常將需求分割成不同的三個部分。資料庫，服務端處理，前端展示。在業務發展的初期，資料量小，功能單一。所以開發、測試、部署都很方便。但是隨著業務的拓展，使用者的增加。系統為了適應市場的需求改變會新增很多不同的功能。導致了單體應用的體積越來越臃腫，占用的資源越來越多，對伺服器的效能要求越來越高，伺服器因此不堪重負，最後宕機。但是，這還不是最後的結果。越來越臃腫的專案導致了**的累積堆疊越來越複雜，後期的維護變得更加困難。反覆的修改打補丁導致系統的穩定性嚴重受損。於是，服務化的架構應運而生
b.服務化的架構
在傳統的網際網路單體服務發展到瓶頸時，出現了服務化的架構。服務化架構已經很類似於微服務架構的理念了。服務化架構的理念就是將乙個大的單體應用拆分成多個小的單體應用，每個應用之間通過暴露的介面來溝通。然後將介面組合成前端對應的資料展示。但是每個應用之間沒有同意管理，應用之間無法確認狀態，此時的系統結構是及其不穩定的。無法水平擴充套件提高吞吐量，很難應對高併發場景。
c.服務匯流排的架構
在服務化架構出現之後，其對應的問題也馬上暴露出來。於是就有了訊息匯流排的架構模式。針對於所有的單體服務都有乙個訊息匯流排來管理。每個服務都要鏈結到訊息匯流排上，由訊息匯流排來維護服務的是否可用。但是，這總模式依然存在水平擴充套件以及訊息匯流排的效能瓶頸問題。
d.微服務的架構
微服務的架構理念集合了服務化以及訊息匯流排。將每乙個單例服務都切割成小的服務，每個服務都有對外暴露的幾口，並註冊到服務管理中心中。服務管理中心依然可以相互註冊，是整個服務成乙個網狀介面，一次來保證高可用性。沒有乙個微服務都可以建成集群註冊在服務治理中心中。
分布式系統解決了網際網路時代的資料爆發以及高併發的吞吐問題。為後續的功能擴充套件以及效能提公升提供了強有力的支援。
注：微服務是一種架構理念，將乙個傳統的單體服務分割成多個不同的服務，每個服務間不依賴，彼此之間以rest格式的介面進行通訊。
為什麼要使用blog
有哥們問我，你為什麼使用blog?我總結了一下，覺得有如下幾個原因。1對自己的督促 有了blog，就會經常記得寫點東西 就會經常翻翻網上的新文章，了解一下新技術，不至於迷失在忙碌的生活中 如果把自己的所感所想所學寫出了，自己對自己也會有個概念，不至於迷迷糊糊 還有，畢竟是掛在網上的文字，心中難免擔心...
為什麼要使用XML
xml 代表擴充套件標記語言 extensible markup language 是由 world wide web consortium w 3c 的 xml工作組定義的。這個工作組是這樣描述該語言的 擴充套件標記語言 xml 是 sgml 的子集，其目標是允許普通的 sgml 在web 上以目...
為什麼要使用Nginx？
有人說這些基準測試是不準確的，因為在這樣那樣的環境下，做的比較不一致。我傾向同意基準測試只是告訴了我們其中一部分情況，你能做的是消除偏見 有人見過所有人都同意乙個基準測試是公平的嗎？我是沒見過。我們投資的一些公司把web平台切換到nginx後，可以顯著的解決擴充套件問題。nginx明顯有效的實現了今...