微服務是乙個很熱門的話題，現在已經有數百個各種形式的會議，網路研討會、流**和網路文章到處是。因此，你會以為每個人都已經意識到微服務提供的好處以及風險。然而，許多公司在沒有事先準備的情況下一下跳入微服務這一趨勢。實際上導致了很多失敗。
乙個智者曾經說過，「在業務中使用的任何技術的第一條規則是自動化適用放大現有效率。第二，自動化應用於低效運營將會放大效率低下「。這一理念也適用於微服務。下面闡述實現微服務架構的五個步驟。
1. 從繪圖開始
許多開發人員在開發某個微服務時，會錯誤地直接編碼。這可能是您最大的錯誤。是的，也許你會成功地服務一下; 然而，隨著人數的增加，整個事情將會變得很大。
像需要建立其他產品一樣，該過程必須從設計開始。通過設計，我的意思是與團隊圍繞桌子聚會，並在紙上(或白板)上繪**務。首先確定您正在構建的應用程式的主要功能。然後，通過自上而下的方法，將其分解成最小的單位。最後，介紹所有這些不同部分的互連性。這些將成為您的微服務的功能。
這個過程將持續超過一天時間，需要很多次迭代才能完成。當然，您需要來自不同部門的許多人的意見，以獲得不同的觀點和觀點，並確保您不會錯過系統的任何功能。
2.微服務不是組織單位
根據貴公司的組織結構定義微服務是很自然的。如果您正在構建乙個單體monolith應用程式，這似乎是乙個適當的解決方案。然而，在實現微服務架構時這可能是錯誤的決定。
也許它可以用於銷售部門或客戶服務，但是許多組織擁有單個部門(資訊中心)來處理所有資料庫。因此，為所有資料庫建立乙個微服務將導致單點故障。這是微服務的關鍵特徵之一 - 沒有單點故障！
您通過您的服務提供的一些功能可能會延伸到幾個組織部門，也可能需要為單個部門構建許多微伺服器。總而言之，您應該將您的架構服從於您要提供的業務功能，而不是您公司的組織結構。
3.建立適當的團隊結構
切換到完全不同的架構一定會要求公司的管理和監控活動有所變化。前兩個步驟的重點是設計應用程式，為您的終端使用者提供正確的功能。現在是時候確保您對新架構有適當的操作支援。
您將不得不放棄舊的部門結構，並圍繞某些微服務組建團隊。這意味著每個團隊將由具有不同技能的各種成員組成，如系統分析師，ux / ui設計師，後端和前端開發人員等。這樣，團隊將從頭到尾負責他們的專案(微服務) - 從開發和部署到運營，監控和管理。這反過來又會增加他們創造他們自己產品的動力。
團隊的規模將由公司/專案的總體規模決定; 然而，專家認為理想的規模是每隊8-10人。此外，與單體架構不同，微服務架構可讓您在擴充套件業務時擴充套件團隊。
當然，所有的團隊都將積極合作直至整個專案的定稿。這導致我們從這種結構中得到的主要好處是 - 更快將最終產品交付到市場。
4.效能和可靠性是重要的，
切換到微服務架構的全部理念是建立乙個比單體架構具有更高效能的最終產品，且更可靠(即具有較低的停機風險)，當然也可以更快地投放市場。
將效能作為設計過程的一部分來解決這個問題很重要，以確保能夠及早考慮任何潛在的問題。通常，微服務設計主要集中在功能問題。但是，如果在第一次遭受較大的負載時崩潰或顯著減慢，則該服務將變得無用。每個服務應該有兩個或三個備選機制，它們可以在其他服務內部潛在資源出現故障時繼續執行，如果在可接受的時間範圍內沒有響應，它應該快速迴圈。
提前考慮讓您的服務能夠準備應付更大負載變化是有好處的，有助於您的應用程式迎接真正的挑戰，讓您在市場上具有競爭優勢，這是您決定首先轉向微服務的主要原因！
5.計畫會變更
忽略應用程式的更改是不可能的。開發人員一直新增和刪除功能; 他們改變**，替換應用程式的核心元素，等等。更正確的說，微服務是不斷發展的。
當您每天多次更新**時，最好接受這種更改也許以後是家常便飯的事情，而不是偶爾為之。一旦認識到這一點，您會意識到從一開始就整合變革所必需的靈活性是很重要的。確保您的應用程式正常工作的一種方法是準備服務api，以便個體微服務可以繼續彼此互動，即使它們發生變化。此外，也應該包括版本控制，以允許新舊服務介面。
另一方面，資料儲存演進更具挑戰性。改變資料表結構以支援新功能傳統上是公升級應用程式中最困難的部分，而微伺服器並沒有使其更容易。nosql資料庫的新技術在新增新字段卻不會中斷現有結構方面表現得更加靈活。如果您期望您的資料儲存技術能夠不斷與時俱進，則應將可演化的資料儲存技術作為微服務設計工作的一部分。
總之，正確準備向微服務架構過渡是整個專案成功的關鍵因素。只有仔細規劃，發揮創新的設計思維，以及正確的運營和管理結構，才能獲得微服務提供的所有好處！
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...
微服務架構
一 先了解一下什麼是單體應用 就是乙個應用程式包含了所有模組功能，各模組同時部署。當然這種應用模式比較容易部署 測試，但隨著專案的加大，單體模式就會變得越來越臃腫，維護的成本逐漸變高。當乙個模組出錯，整個應用都會出現問題，擴充套件能力也會受到限制。二 什麼是微服務 是將整個應用程式分解為多個模組，各...
微服務架構
簡單來說，微服務架構風格想要開發一種由多個小服務組成的應用，每個服務執行於獨立的程序，並且採用輕量級互動，多數情況下乙個http的資源api，這些服務具備獨立業務能力並可以通過自動化部署方式獨立部署，這種風格使最小化集中管理，從而可以使用多種不同的程式語言喝資料儲存技術 james lewis 和 ...