回答關(guān)于微服務(wù)的幾點(diǎn)老板關(guān)心問(wèn)題

單體系統(tǒng)在初期可以實(shí)現(xiàn)比較方便地開發(fā)與使用，但是隨著系統(tǒng)的發(fā)展，維護(hù)成本變大，且難以控制（當(dāng)一個(gè)系統(tǒng)業(yè)務(wù)復(fù)雜且架構(gòu)設(shè)計(jì)不合理，同時(shí)以前的開發(fā)者之間沒(méi)有什么規(guī)范的時(shí)候，后續(xù)新人對(duì)于功能的修改、維護(hù)、完善都必須建立在對(duì)系統(tǒng)整體業(yè)務(wù)的把握上，這也對(duì)開發(fā)人員提出了更高要求）。

引進(jìn)微服務(wù)架構(gòu)體系作為后續(xù)主體架構(gòu)，將不同的模塊拆分成多個(gè)不同的服務(wù)，服務(wù)能夠?qū)崿F(xiàn)獨(dú)立的部署與擴(kuò)展，且不同的服務(wù)都運(yùn)行在自己的進(jìn)程中，由于部署存在穩(wěn)定的邊界，這樣每個(gè)服務(wù)的更新都不會(huì)影響到其他服務(wù)的運(yùn)行，也更方便后續(xù)整體架構(gòu)的水平擴(kuò)展。同時(shí)平衡需求的多變和軟件工程本身的技術(shù)復(fù)雜性的矛盾，從而在應(yīng)用開發(fā)小團(tuán)隊(duì)中推行敏捷開發(fā)開發(fā)模式。

1、開發(fā)效率能提高嗎？

• 在單體架構(gòu)中，隨著業(yè)務(wù)的發(fā)展，代碼會(huì)越來(lái)越多，變得臃腫，編譯、啟動(dòng)、打包、發(fā)布會(huì)變得越來(lái)越慢。
• 一個(gè)小功能的改動(dòng)，重啟都需要等待幾分鐘，導(dǎo)致很多的時(shí)間會(huì)浪費(fèi)在這個(gè)過(guò)程中。
• 由于業(yè)務(wù)的變化性較高，使得各個(gè)業(yè)務(wù)的代碼交互變得復(fù)雜，如果維護(hù)不當(dāng)，會(huì)導(dǎo)致這些代碼難以維護(hù)。 如果進(jìn)行維護(hù)，就算只改動(dòng)了一個(gè)小功能，也可能會(huì)影響到N個(gè)模塊業(yè)務(wù)。
• 在微服務(wù)的體系下，將不同的業(yè)務(wù)層劃分成各個(gè)不同的業(yè)務(wù)模塊，使得模塊間的耦合度降低，方便維護(hù)。
• 每個(gè)業(yè)務(wù)模塊獨(dú)立成一個(gè)微服務(wù)，由不同的人員（團(tuán)隊(duì)）來(lái)維護(hù)，達(dá)到可以獨(dú)立開發(fā)和獨(dú)立部署。
• 分工明確，代碼邏輯清晰、代碼量小，可維護(hù)性高，整體提高開發(fā)效率。

2、產(chǎn)品質(zhì)量能提高嗎？

單體架構(gòu)是將所有業(yè)務(wù)功能全部集中在一個(gè)系統(tǒng)服務(wù)中，如果某個(gè)業(yè)務(wù)突發(fā)請(qǐng)求，或者異常，可能會(huì)導(dǎo)致整個(gè)系統(tǒng)宕機(jī)。

微服務(wù)體系中，會(huì)將不同的業(yè)務(wù)劃分成不同的服務(wù)，各個(gè)服務(wù)會(huì)使用多個(gè)服務(wù)進(jìn)行負(fù)載、容錯(cuò)、隔離。如果某個(gè)服務(wù)宕機(jī)，不會(huì)影響到整個(gè)系統(tǒng)的正常運(yùn)行。

3、代碼的執(zhí)行效率能提高嗎？

代碼的執(zhí)行效率與算法和設(shè)計(jì)有關(guān)系。微服務(wù)只解決了業(yè)務(wù)的劃分之后服務(wù)治理與服務(wù)調(diào)用，對(duì)業(yè)務(wù)代碼的執(zhí)行效率不會(huì)有明顯的改善，但是在改造的過(guò)程中，會(huì)逐步修復(fù)算法與設(shè)計(jì)的問(wèn)題。

4、可擴(kuò)展性如何？支持靈活的二次開發(fā)嗎？以什么形式來(lái)支持呢？

微服務(wù)可以根據(jù)業(yè)務(wù)情況，對(duì)高并發(fā)業(yè)務(wù)或者需要高保障的業(yè)務(wù)進(jìn)行快速的橫向擴(kuò)容。

微服務(wù)以組件化的形式存在，可以根據(jù)公司不同的業(yè)務(wù)場(chǎng)景，滿足各種定制化需求，快速交付。

微服務(wù)對(duì)后續(xù)PaaS平臺(tái)的研發(fā)和支持提供了基礎(chǔ)技術(shù)保障。

5、服務(wù)器成本如何？與現(xiàn)在是持平還是更節(jié)省？還是更高？

由于微服務(wù)都是運(yùn)行在獨(dú)立的容器中，相比ECS，大大節(jié)約了CPU與內(nèi)存的使用率。

對(duì)資源的要求相對(duì)單體系統(tǒng)來(lái)說(shuō)整體降低。

單體架構(gòu)只需要一個(gè)獨(dú)立的pod容器，但是在微服務(wù)中，每個(gè)獨(dú)立服務(wù)都需要一個(gè)獨(dú)立的pod容器。

獨(dú)立服務(wù)的容錯(cuò)、負(fù)載（一個(gè)業(yè)務(wù)服務(wù)運(yùn)行在多個(gè)進(jìn)程/容器中），則需要消耗更多的系統(tǒng)資源。

在微服務(wù)體系中，資源與容錯(cuò)能力是成正比的。容錯(cuò)能力越強(qiáng)，則消耗的資源越多。

6、后續(xù)的運(yùn)維成本如何？

微服務(wù)體系物理架構(gòu)在后續(xù)水平擴(kuò)展方面可減少服務(wù)器數(shù)量和降低對(duì)服務(wù)器配置要求（高頻/高可用微服務(wù)和低頻/低可用微服務(wù)可分別部署至不同配置的服務(wù)器上。

微服務(wù)體系中每個(gè)服務(wù)都可以獨(dú)立部署（高內(nèi)聚低耦合），這樣每個(gè)服務(wù)的更新都不會(huì)影響到其他服務(wù)的運(yùn)行或影響范圍可控，也更方便后續(xù)整體架構(gòu)的水平擴(kuò)展。

對(duì)于運(yùn)維人員的要求： 掌握全鏈路監(jiān)測(cè)、灰度發(fā)布，掌握基礎(chǔ)微服務(wù)知識(shí)等相關(guān)能力。

對(duì)于測(cè)試人員的要求： 混沌測(cè)試（全鏈路測(cè)試）。

微服務(wù)架構(gòu)體系加持續(xù)集成方案帶來(lái)的預(yù)期收益主要有：

• 系統(tǒng)水平擴(kuò)展能減少應(yīng)用服務(wù)器需求數(shù)量和降低對(duì)服務(wù)器的性能要求；
• 快速響應(yīng)業(yè)務(wù)部門的需求（系統(tǒng)短周期開發(fā)，測(cè)試，發(fā)布迭代的敏捷開發(fā)模式）；
• 相對(duì)單體系統(tǒng)降低開發(fā)人員的開發(fā)成本（微服務(wù)功能原子化）及管理成本（持續(xù)構(gòu)建，靜態(tài)代碼檢測(cè)，部署自動(dòng)化）；
• 系統(tǒng)水平擴(kuò)展更便捷（子系統(tǒng)以微服務(wù)熱發(fā)布集成）；
• 系統(tǒng)穩(wěn)定性更好（前后端分離，服務(wù)流量控制，服務(wù)健康檢查，服務(wù)調(diào)度可監(jiān)控及可追溯）。