時至今日，微服務(wù)相關(guān)的話題不勝枚舉，上百次的會議，在線討論以及相關(guān)文章。你可以假設(shè)大家已經(jīng)認識到其優(yōu)點以及與之俱來的風(fēng)險。然而，有很多組織沒有事先準備就邁入這個潮流了。自然，這也就導(dǎo)致了在架構(gòu)實現(xiàn)過程中的失敗。

有一位智者曾經(jīng)說過，“對于商業(yè)中所應(yīng)用的任何技術(shù)而言，有2條規(guī)則，其一，將自動化應(yīng)用于高效的運維上才能增加效率;其二，將自動化應(yīng)用于低效的運維反而會降低效率。”我認為這種哲學(xué)對微服務(wù)而言亦行之有效。如果你的組織沒有為此準備就貿(mào)然遷移，很可能會招致失敗。以上就是本文的出發(fā)點，我將為大家?guī)碓趯崿F(xiàn)微服務(wù)架構(gòu)前需要準備的5個關(guān)鍵步驟。

1. 從繪圖入手

在開發(fā)特定的微服務(wù)時，許多開發(fā)者都會犯同一個錯誤：直接寫代碼?；蛟S，這可能就是你能夠犯的最嚴重的錯誤了。誠然，對于一個服務(wù)而言，你可能會獲得成功，但是隨著服務(wù)數(shù)量的上升，所有事情都會變得一團亂。和其它產(chǎn)品一樣，它也需要被創(chuàng)造，需要以設(shè)計作為初始步驟。將團隊匯聚到桌子周圍，自由地在紙上(或者白板)繪制服務(wù)。首先，找出你所構(gòu)建的應(yīng)用的main函數(shù)。然后，自頂向下地將它分解成最小單元。***，找出不同單元的互聯(lián)通性。這些功能將會成為你的微服務(wù)。

比如，在一款圖書預(yù)覽應(yīng)用中，其主要的功能就是比較不同的圖書。然而，也有許多其他功能需要開發(fā)，例如創(chuàng)建用戶履歷，評分，評論，圖書數(shù)據(jù)庫等。識別每個功能，是將它們轉(zhuǎn)為微服務(wù)的關(guān)鍵。

整個過程將會持續(xù)超過一天時間，并且需要多次迭代直至***。當然，你將需要從許多不同部門的人員手中獲得輸入，以確保能夠知曉其視角和觀點，并確保你不會遺漏任何系統(tǒng)功能。

2. 微服務(wù)并不是組織結(jié)構(gòu)

根據(jù)你所在公司的組織結(jié)構(gòu)定義微服務(wù)，這似乎是很自然的。如果你正在構(gòu)建單體(monolithic)應(yīng)用，這或許真是一個恰當?shù)慕鉀Q方案。但是，在實現(xiàn)微服務(wù)架構(gòu)時，它可能就是一個錯誤的決定了。

也許，這對于銷售部門或客戶服務(wù)是可行的，但是許多組織只有一個部門處理所有的數(shù)據(jù)庫。因此，為所有數(shù)據(jù)庫創(chuàng)建一個微服務(wù)將會導(dǎo)致單點故障。而沒有單點故障，則是微服務(wù)的關(guān)鍵特性之一。

你希望通過服務(wù)實現(xiàn)的一些功能可能會涉及幾個組織部門，或者，你可能將會需要為一個部門構(gòu)建許多微服務(wù)。總結(jié)一下，你需要將架構(gòu)聚焦于你想要提供的服務(wù)，而非你們公司的組織結(jié)構(gòu)。

3. 創(chuàng)建合適的組織結(jié)構(gòu)

轉(zhuǎn)變到一個全然不同的組織架構(gòu)，能夠滿足公司在管控活動上變化的需要。之前2個步驟關(guān)注于應(yīng)用的設(shè)計，以便能夠為最終用戶提供正確的功能。現(xiàn)在，是時候確保對于新的架構(gòu)而言，你擁有恰當?shù)倪\維支持了。

你將不得不放棄原有的部門結(jié)構(gòu)，并使團隊關(guān)注于某個微服務(wù)。這意味著這些團隊將由擁有不同技能的成員組成，如系統(tǒng)分析師、UX/UI設(shè)計師、后端工程師、前端工程師等。如此一來，團隊就能夠徹底負責(zé)它們的項目(微服務(wù))——從開發(fā)部署到運維、監(jiān)控和管理。反過來，由于團隊覺得自己擁有這個產(chǎn)品，因此將提升其創(chuàng)建產(chǎn)品的積極性。

團隊的規(guī)模視公司/項目的總體人數(shù)而定;當然，根據(jù)專家的建議，比較理想的規(guī)模是每個團隊8-10人。和單體架構(gòu)不同，微服務(wù)架構(gòu)使得你能夠根據(jù)業(yè)務(wù)的增長來擴展團隊規(guī)模。

當然，所有團隊將會(需要)積極配合，以最終促成整個項目。這便是這種結(jié)構(gòu)的主要好處，使我們能夠盡可能快地向市場交付產(chǎn)品。

4. 性能和可靠性同樣重要

切換到微服務(wù)架構(gòu)的整體想法，便是使得創(chuàng)建的最終產(chǎn)品相比于單體應(yīng)用而言擁有更好的性能，更佳的穩(wěn)定性(例如，更低的下線風(fēng)險)，同時可以更快地交付市場。將改進性能作為設(shè)計的一部分是很重要的，這將確保潛在問題能夠盡早被考慮。通常，(性能)問題都源自微服務(wù)設(shè)計主要考慮功能。然而，如果在更大的服務(wù)下，服務(wù)崩潰或者變得很慢，那么它就沒什么用了。每個服務(wù)應(yīng)該擁有2-3個替代機制，當下層資源失敗時，它便可以繼續(xù)運作。當其中一個機制無法在可接受時間窗口內(nèi)響應(yīng)時，服務(wù)也需要做到快速切換。

在前期考慮讓服務(wù)支持更大的負載變動，你的應(yīng)用將能夠應(yīng)對實際挑戰(zhàn)，你將領(lǐng)先市場，當然這也是你在***時間考慮切換到微服務(wù)的主要原因!

5. 變更先行

忽略應(yīng)用的變化是不切實際的。開發(fā)者一直在增加和移除功能，變更代碼，替換應(yīng)用的核心元素等，這在微服務(wù)應(yīng)用中更甚。更確切地說，微服務(wù)就是持續(xù)演進的。當你每天需要處理多次代碼升級時，***接受一個觀點：變更是持續(xù)的，而非對于穩(wěn)定狀態(tài)的一次偶然性中斷。一旦你認知到這一點，你將意識到一開始便整合變更的靈活性需求的重要性。確保應(yīng)用一直正常工作的一種方式便是準備服務(wù)API，這樣微服務(wù)間便可繼續(xù)通信，即使它們已被改變。另外，你還需要引入版本控制，以允許服務(wù)同時開放新舊接口。另一方面，數(shù)據(jù)存儲的演進是一個更大的挑戰(zhàn)。改進數(shù)據(jù)庫模式(schema)，使其支持新的功能，傳統(tǒng)觀點中，這是應(yīng)用升級時最難處理的部分，微服務(wù)并不會使其變得更加簡單。然而，單就增加新的域且不破壞現(xiàn)有結(jié)構(gòu)這一點而言，NoSQL數(shù)據(jù)庫會更加靈活。如果你希望你的數(shù)據(jù)存儲需求持續(xù)演進(誰不希望呢?)，那么你應(yīng)該將可演化的數(shù)據(jù)存儲作為微服務(wù)設(shè)計的努力方向之一。

在遷移到微服務(wù)架構(gòu)時，做適當?shù)臏蕚涫钦麄€項目成功的關(guān)鍵因素，這一點我們可以認同。只有經(jīng)過仔細的準備，創(chuàng)新設(shè)計思維，并且具備合適的運維和管理結(jié)構(gòu)，你才能收獲微服務(wù)帶來的所有好處!