微服務架構：微服務化後系統架構要如何改造？
隨着業務功能的增加，當前系統依賴資源的擴展出現問題，一體架構在研發正本，部署成本上帶來問題時，考慮將一體架構做微服務化拆分。
在對服務進行拆分的過程中，需要考慮的問題：
- 服務拆分要遵循哪些原則
- 服務的邊界如何確定
- 微服務化後會帶來哪些問題，如何解決這些問題。
1 微服務拆分的原則
1.1 單一服務內部功能的高內聚和低耦合
每個服務只完成自己職責之內的任務，對於不是自己職責的功能交個其他服務來完成
1.2 需要關注服務拆分的粒度，先粗略拆分再逐漸細化。
拆分初期可以把服務粒度拆得粗一些，後面隨着團隊對於業務和微服務理解的加深，再考慮把服務粒度細化
1.3 拆分的過程，儘量避免影響產品的日常功能迭代
一邊做產品功能迭代，一邊完成服務化拆分
1.4 服務接口的定義要具備可擴展性
服務拆分之後，各個服務的通信變爲了網絡請求，在定義接口的參數時，參數類型最好是封裝類，這樣添加參數就不必變更接口了，只需要在封裝類中添加字段就好了。
2 微服務帶來的問題和解決思路
微服務是一種架構手段，有效拆分可以幫助實現服務的敏捷開發和部署，但微服務是通過網絡通信的分佈式服務，如何在分佈式環境下協調多個服務正常運行，引入了一定的複雜度。
- 服務接口間調用變爲了跨進程的網絡調用
- 多個服務之間有着比較複雜的依賴關係
- 一個服務依賴多個其他服務同時也會被其他服務所依賴，一旦一個服務性能出現問題，可能會影響其他服務。需要引入服務治理體系和對出現問題的服務進行熔斷、降級、限流、超時控制等方法
- 服務拆分後，一條請求的調用鏈路上涉及多個服務，一旦這個請求的響應長或者出錯，很難快速定位問題，需要引入分佈式追蹤工具，服務端監控來解決。