微服務(wù)是什么
拋去教條性質(zhì)的解釋，從巨石應(yīng)用到微服務(wù)應(yīng)用，耦合度是其中最大的變化。或是將多個模塊中重復(fù)的部分進行拆分，或是純粹為了拆分膨脹的單體應(yīng)用，這些拆分出來的部分獨立成一個服務(wù)單獨部署與維護，便是微服務(wù)了。
拆分后自然而然會催生出一些必要的需求：
- 從本地方法調(diào)用的關(guān)系衍變成遠程過程調(diào)用的關(guān)系，那么可靠的通信功能是首要的。
- 隨著拆分工作的推進，資源調(diào)度關(guān)系會變得錯綜復(fù)雜，這時候需要完善的服務(wù)治理。
- 調(diào)用關(guān)系網(wǎng)的整體復(fù)雜化還會給我們帶來更大的風險，即鏈式反應(yīng)導致服務(wù)雪崩的可能性，所以如何保障服務(wù)穩(wěn)定性也是微服務(wù)架構(gòu)中需要考慮的。
- 這點就不是內(nèi)需而算是自我演進了，服務(wù)化后，如果能結(jié)合容器化、Devops技術(shù)實現(xiàn)服務(wù)運維一體化，將大大降低微服務(wù)維護的成本，不管是現(xiàn)在還是將來。
微服務(wù)是什么樣的
從微服務(wù)自身角度來看，則大致會包含以下這些模塊:
服務(wù)化的前提
是不是只要套上微服務(wù)框架就算是一個微服務(wù)了呢？雖然這樣有了微服務(wù)的表，但卻沒有微服務(wù)的實質(zhì)，即”微“。
微服務(wù)化的前提是服務(wù)拆分到足夠”微“，足夠單一職責，當然拆分程度與服務(wù)邊界都需要結(jié)合業(yè)務(wù)自行把握。
廣義的服務(wù)拆分即包含了應(yīng)用拆分，也包含了數(shù)據(jù)拆分。
應(yīng)用拆分后需要引入微服務(wù)框架來進行服務(wù)通信與服務(wù)治理，這也就是傳統(tǒng)定義上的微服務(wù)。
數(shù)據(jù)拆分后同樣需要引入一系列手段來進行保障，由于不是與微服務(wù)強相關(guān)的話題，在此只做簡單闡述:
- 分布式id
- 新表優(yōu)化
- 數(shù)據(jù)遷移與數(shù)據(jù)同步
- sql調(diào)用方案改造
- 切庫方案
- 數(shù)據(jù)一致性
