微服務的優(yōu)與劣

微服務是一場架構層面的變革，而 Go 由于其簡單實用的語法、編譯快、可執(zhí)行文件小等特點，是微服務所依賴的底層基礎設施常用語言，這也許會為 Go 開發(fā)者進一步學習提供一定的基礎，但“千里之行始于足下”，如果不認真去學，一步一個腳印，知識也不會憑空而來。

微服務是未來軟件開發(fā)的首選，以后每個開發(fā)、每個公司都會選擇它，但我們都知道：“軟件開發(fā)沒有'銀彈'”，一個事物，如果它的優(yōu)勢越明顯，那么它的劣勢也越明顯，而且一般來說，它的劣勢就是它優(yōu)勢的反面。

微服務優(yōu)勢可以總結有如下幾點：

業(yè)務代碼和技術代碼分離

原先在框架內部的代碼如負載均衡、服務注冊、熔斷限流、鏈路追蹤等等，均沉淀到技術底層，對業(yè)務的開發(fā)人員透明化，業(yè)務開發(fā)人員可以更好的思考用什么語言、什么存儲去實現服務邏輯，而不必受到框架的限制。

快速迭代，穩(wěn)定發(fā)布

微服務專注于一項功能，且有清晰的接口邊界。這樣，無論是迭代升級，還是完全推到重來，改造的成本都比較小。而且，由于底層調度系統的支持，發(fā)布服務時再也不用等到凌晨用戶量少的時候偷偷更新一下，發(fā)布變得更快速更穩(wěn)定。

簡化開發(fā)步驟，提升效率

微服務化以后，對于普通開發(fā)人員而言，負擔是更輕了的，技術代碼的抽離使底層技術成為黑盒，開發(fā)新服務只需要一個輕量的框架，快速配置一下即可馬上開始開發(fā)，夢回 SpringBoot 時代。

而微服務的劣勢，同樣也是三點：

沉重的技術架構帶來的考驗

代碼的分離勢必導致團隊內對底層服務的了解更少了，即使團隊內有人愿意去學習，一方面可能了解的人不愿意花心思科普；另一方面自己也有沉重的業(yè)務開發(fā)負擔，精力不夠。

所以有關微服務的書籍都會不約而同的提到“康威定律”，就是要求這些分離出去的技術設施需要獨立團隊維護。自從阿里提出“中臺化”戰(zhàn)略后，這些基礎設施也有高大上的名字：“技術中臺”。

但理想很豐滿，現實很骨感。個團隊在中小型公司存活的概率不大，一方面這些設施的建設是長期工程，短期難見成效；另一方面，這個團隊在內部推行新設施的阻力也是比較大的，容易遭到業(yè)務側的反對。

可是這個團隊無法成立，微服務就只能淪為拆服務的游戲。

DevOps 的要求

微服務同樣對運維團隊提出了更高的要求，也就是現在常聽的“DevOps”。原先發(fā)布可能就是丟個包上去就行，那些“build once , run anywhere”什么的口號都是廣告，實際上普通的公司也沒那么多的平臺需求。

現在發(fā)布要搭建一套自動化發(fā)布流，與“技術中臺”團隊有更多的重合部分。實際上問題和“技術中臺”團隊碰到的差不多，效益和推廣問題。

普通開發(fā)者能更快的開發(fā)程序，關注更少的架構側的變化，對公司是好事，對個人不見得是好事。在優(yōu)化基礎設施的過程中鞏固自己的知識，能通過學習改變自己。

最后也為對Go語言感興趣的朋友整理了一些go語言資源，希望可以幫到大家。