2018-11-15 香格里拉 從單體應用到服務化結構 會後總結整理
首先,這個內容很高大上,很有挑戰性,我根本不會,以前瞭解的也接近於零,此處只是整理會上的梳理和讓自己有此部分內容有個基本概念和記錄,以便在之後可能會用到和學習.
會議核心內容概括:
1.單體應用架構的侷限性
2.服務化架構解決方案(嘗試中)
3.服務化中遇到的挑戰
一 單體應用
單體應用概念：在專案中只需要通過引用把所有的功能集中在同一系統中實現 二 單體應用的優點
（1）易於開發：開發人員使用當前開發工具在短時間內就可以開發出單體應用.（IDE友好）
（2）易於測試：因為不需要依賴其他介面，測試可以節約相當多時間了。
（3）易於部署：你只需要將目錄部署在執行環境中即可
三 單體應用的缺陷
(1) 釋出構建緩慢
(2) 程式碼庫巨大,冗餘程式碼越來越多;業務職責越來越模糊,反正知道表在哪裡就OK了,一個sql語句搞定了,那麼這個時候還需要進行更加複雜的工作,在細分職責嗎? (由此引發的問題)
(3) 相同的業務在不同應用中存在不一致的問題
(4) 業務模組之間的依賴混亂
(5) 某個業務模組有問題,會導致整個應用停止服務?
(6) 擴充套件能力受限,只能對整個應用進行擴充套件,不能針對不同模組特性進行擴充套件(計算密集型和IO密集型)
(7) 對現有模組的依賴太嚴重,難以引入新的技術.
四 對現有問題的解決辦法
- publiccode抽象公共業務元件
- extapi提供資料介面
- 資料同步,資料依賴
五 服務化能帶來什麼
- 鬆耦合
- 業務內聚，易於重用
- 獨立開發，測試，部署和釋出
- 快速迭代
- 故障隔離，易於服務降級
- 服務易於擴充套件，靈活性高
- 平臺不相關，利於創新
六 服務化過程中可能遇到的挑戰
- 服務劃分
- 服務治理
- 分散式事務
- 自動化部署體系devops
- 團隊組織的調整
- 人員的技術能力提升
七 服務化的必要性
- 快速試錯性產品不適合做服務化
- 公共業務和基礎設施服務可以做服務化
- 業務不斷的發展後，必然需要服務化
宣告: 以上內容來源於
- 單體架構與微服務架構部落格
- 結構初識
- 雲客楊小松分享會上內容整理