【編者的話】本文為大家介紹了5個遷移到微服務架構所需做的準備步驟，包括如何劃分微服務，微服務和組織結構間的誤解，如何劃分組織架構，以及在實現微服務架構中需要盡早考慮的一些問題，值得大家參考。
【3 天燒腦式容器儲存網路訓練營 | 深圳站】本次培訓以容器儲存和網路為主題，包括：docker plugin、docker storage driver、docker volume pulgin、kubernetes storage機制、容器網路實現原理和模型、docker網路實現、網路外掛程式、calico、contiv netplugin、開源企業級映象倉庫harbor原理及實現等。
有一位智者曾經說過，「對於商業中所應用的任何技術而言，有2條規則，其一，將自動化應用於高效的運維上才能增加效率；其二，將自動化應用於低效的運維反而會降低效率。」我認為這種哲學對微服務而言亦行之有效。如果你的組織沒有為此準備就貿然遷移，很可能會招致失敗。以上就是本文的出發點，我將為大家帶來在實現微服務架構前需要準備的5個關鍵步驟。
在開發特定的微服務時，許多開發者都會犯同乙個錯誤：直接寫**。或許，這可能就是你能夠犯的最嚴重的錯誤了。誠然，對於乙個服務而言，你可能會獲得成功，但是隨著服務數量的上公升，所有事情都會變得一團亂。
和其它產品一樣，它也需要被創造，需要以設計作為初始步驟。將團隊匯聚到桌子周圍，自由地在紙上（或者白板）繪**務。首先，找出你所構建的應用的main函式。然後，自頂向下地將它分解成最小單元。最後，找出不同單元的互聯通性。這些功能將會成為你的微服務。
整個過程將會持續超過一天時間，並且需要多次迭代直至完美。當然，你將需要從許多不同部門的人員手中獲得輸入，以確保能夠知曉其視角和觀點，並確保你不會遺漏任何系統功能。
根據你所在公司的組織結構定義微服務，這似乎是很自然的。如果你正在構建單體（monolithic）應用，這或許真是乙個恰當的解決方案。但是，在實現微服務架構時，它可能就是乙個錯誤的決定了。
也許，這對於銷售部門或客戶服務是可行的，但是許多組織只有乙個部門處理所有的資料庫。因此，為所有資料庫建立乙個微服務將會導致單點故障。而沒有單點故障，則是微服務的關鍵特性之一。
你希望通過服務實現的一些功能可能會涉及幾個組織部門，或者，你可能將會需要為乙個部門構建許多微服務。總結一下，你需要將架構聚焦於你想要提供的服務，而非你們公司的組織結構。
轉變到乙個全然不同的組織架構，能夠滿足公司在管控活動上變化的需要。之前2個步驟關注於應用的設計，以便能夠為終端使用者提供正確的功能。現在，是時候確保對於新的架構而言，你擁有恰當的運維支援了。
你將不得不放棄原有的部門結構，並使團隊關注於某個微服務。這意味著這些團隊將由擁有不同技能的成員組成，如系統分析師、ux/ui設計師、後端工程師、前端工程師等。如此一來，團隊就能夠徹底負責它們的專案（微服務）——從開發部署到運維、監控和管理。反過來，由於團隊覺得自己擁有這個產品，因此將提公升其建立產品的積極性。
團隊的規模視公司/專案的總體人數而定；當然，根據專家的建議，比較理想的規模是每個團隊8-10人。和單體架構不同，微服務架構使得你能夠根據業務的增長來擴充套件團隊規模。
當然，所有團隊將會（需要）積極配合，以最終促成整個專案。這便是這種結構的主要好處，使我們能夠盡可能快地向市場交付產品。
切換到微服務架構的整體想法，便是使得建立的最終產品相比於單體應用而言擁有更好的效能，更佳的穩定性（例如，更低的下線風險），同時可以更快地交付市場。
將改進效能作為設計的一部分是很重要的，這將確保潛在問題能夠盡早被考慮。通常，（效能）問題都源自微服務設計主要考慮功能。然而，如果在更大的服務下，服務崩潰或者變得很慢，那麼它就沒什麼用了。每個服務應該擁有2-3個替代機制，當下層資源失敗時，它便可以繼續運作。當其中乙個機制無法在可接受時間視窗內響應時，服務也需要做到快速切換。
在前期考慮讓服務支援更大的負載變動，你的應用將能夠應對實際挑戰，你將領先市場，當然這也是你在第一時間考慮切換到微服務的主要原因！
忽略應用的變化是不切實際的。開發者一直在增加和移除功能，變更**，替換應用的核心元素等，這在微服務應用中更甚。更確切地說，微服務就是持續演進的。
當你每天需要處理多次**公升級時，最好接受乙個觀點：變更是持續的，而非對於穩定狀態的一次偶然性中斷。一旦你認知到這一點，你將意識到一開始便整合變更的靈活性需求的重要性。確保應用一直正常工作的一種方式便是準備服務api，這樣微服務間便可繼續通訊，即使它們已被改變。另外，你還需要引入版本控制，以允許服務同時開放新舊介面。
另一方面，資料儲存的演進是乙個更大的挑戰。改進資料庫模式（schema），使其支援新的功能，傳統觀點中，這是應用公升級時最難處理的部分，微服務並不會使其變得更加簡單。然而，單就增加新的域且不破壞現有結構這一點而言，nosql資料庫會更加靈活。如果你希望你的資料儲存需求持續演進（誰不希望呢？），那麼你應該將可演化的資料儲存作為微服務設計的努力方向之一。
在遷移到微服務架構時，做適當的準備是整個專案成功的關鍵因素，這一點我們可以認同。只有經過仔細的準備，創新設計思維，並且具備合適的運維和管理結構，你才能收穫微服務帶來的所有好處！
建立微服務架構的步驟 通向微服務成功的五個步驟
微服務是乙個很熱門的話題，現在已經有數百個各種形式的會議，網路研討會 流 和網路文章到處是。因此，你會以為每個人都已經意識到微服務提供的好處以及風險。然而，許多公司在沒有事先準備的情況下一下跳入微服務這一趨勢。實際上導致了很多失敗。乙個智者曾經說過，在業務中使用的任何技術的第一條規則是自動化適用放大...
基於REST微服務的5個最佳實踐
原文 5 best practices for rest based microservices 翻譯 vincent 如果想讓微服務架構開發變得友好，而且可以讓開發者管理起來輕鬆一些，跟蹤誤差更容易，那麼只要遵循本文中討論的5個最佳實踐就可以了。1.使用者 在請求頭裡面命名有意義的名字是非常重要的...
確保BPM成功的五個步驟
確保 bpm成功的五個步驟 制訂企業 bpm策略是一項複雜的任務，涉及許多步驟和人員，採取本文的五個步驟將幫助你確定與戰略目標相一致的重要專案。眾所周知，業務流程管理 bpm 可以帶來以下好處 簡化流程 改善客戶服務 提高法規遵守效率 改進風險管理 加強應對不斷變化的商業環境的響應能力，不過前提是 ...