架構的演進
微服務&分布式關係
微服務&分布式理解
引言
單體架構（monolithic）
缺點：留白
soa 架構（service oriented architecture）
你說了這麼多，但我還是不知道soa是個什麼鬼啊？你能說的通熟易懂點兒麼？
有什麼優點嗎？
說了這麼多優點，不可能一點缺點都沒有吧，不要王婆賣瓜自賣自誇哈…
soa架構圖
esb架構圖(簡)
總結
系統的服務化【復用】
業務的服務化【高效】
微服務架構（microservices）
主要挑戰：
微服務架構和 soa 架構非常類似,微服務只是的 soa 昇華，只不過微服務架構強調的是「業務需要徹底的元件化及服務化」，原單個業務系統會被拆分為多個可以獨立開發、設計、部署執行的小應用。這些小應用間通過服務化完成互動和整合。 元件表示的就是乙個可以獨立更換和公升級的單元，就像 pc 中的 cpu、記憶體、顯示卡、硬碟一樣，獨立且可以更換公升級而不影響其他單元。若我們把 pc 中的各個元件以服務的方式構 建，那麼這台 pc 只需要維護主機板（可以理解為esb）和一些必要的外部裝置就可以。cpu、記憶體、硬碟等都是以元件方式提供服務，例如pc 需要呼叫 cpu 做計算處理，只需知道 cpu 這個元件的位址就可以了。
松耦合
ddd（領域驅動設計）的思想進行設計領域模型，服務間儘量減少同步的呼叫，多使用訊息的方式讓服務間的領域事件來進行解耦輕量級協議
更傾向於使用 restful 風格的 api，輕量級的協議可以很好地支援跨語言開發的服務，並且restful 風格的api 便於理解高度自治和持續整合
微服務可以很好得和容器技術結合，容器技術比微服務出現得晚，但是容器技術的出現讓微服務的實施更加簡
便，目前 docker 已經成為很多微服務實踐的基礎容器， 因為容器的特色，所以一台機器上可以部署幾十個、
幾百個不同的微服務。如果某個微服務流量壓力比其他微服務大，可以在不增加機器的情況下，在一台機器上
多分配一些該微服務的容器例項。同時，因為 docker 的容器編排社群日漸成熟，類似 mesos、kubernetes 及
docker 官方提供的 swarm 都可以作為持續整合部署的技術選擇
微服務 分布式架構演變之路
最近兩個月因為一點破事停止了更新，真的是哭出了聲音。但是還好，之前說的微服務系列也算是開始了！大家有什麼建議可以提！這章講的是分布式架構的演變之路。1.單體應用架構 2.垂直架構 3.分布式架構 微服務 最開始的應用架構，是一台伺服器，開個web服務，乙個資料庫服務。這時候的應用效能受伺服器效能影響...
架構模式的演變之路 從單體架構到微服務架構
談到軟體系統設計的方 在 層面，有我們熟悉的23種設計模式 design pattern 對應到架構層面，則有所謂的架構模式 architecture pattern 它們分別從微觀和巨集觀的角度指導著我們設計出良好的軟體系統，因此，作為乙個軟體工程師，我們不僅要熟悉設計模式，對常見的架構模式也要熟...
為什麼要用RPC,或者微服務」架構的演變
我們在做乙個訪問量不大的專案的時候,一台伺服器上面部署乙個應用 資料庫就夠用了 那麼訪問量稍微大一點的話,使用者就會說卡頓,反應慢 等等各種情況,這個時候呢我們就用集群 架設nginx 部署多個服務 由nginx 負載均衡 負責把請求 到其他伺服器上,這樣就解決了使用者說的反應慢的問題 過了一段時間...