通向微服務成功的五個步驟
微服務是一個很熱門的話題,現在已經有數百個各種形式的會議,網路研討會、流媒體和網路文章到處是。因此,你會以為每個人都已經意識到微服務提供的好處以及風險。然而,許多公司在沒有事先準備的情況下一下跳入微服務這一趨勢。實際上導致了很多失敗。
一個智者曾經說過,“在業務中使用的任何技術的第一條規則是自動化適用放大現有效率。第二,自動化應用於低效運營將會放大效率低下“。這一理念也適用於微服務。下面闡述實現微服務架構的五個步驟。
1. 從繪圖開始
許多開發人員在開發某個微服務時,會錯誤地直接編碼。這可能是您最大的錯誤。是的,也許你會成功地服務一下; 然而,隨著人數的增加,整個事情將會變得很大。
像需要建立其他產品一樣,該過程必須從設計開始。透過設計,我的意思是與團隊圍繞桌子聚會,並在紙上(或白板)上繪製服務。首先確定您正在構建的應用程式的主要功能。然後,透過自上而下的方法,將其分解成最小的單位。最後,介紹所有這些不同部分的互連性。這些將成為您的微服務的功能。
例如,在書籍評論系統中,主要功能是比較不同的書籍。然而,必須開發許多其他功能,例如建立使用者配置檔案,評級,評論,書籍資料庫等。確定每個功能對於將它們捕獲到微服務中都是至關重要的。
這個過程將持續超過一天時間,需要很多次迭代才能完成。當然,您需要來自不同部門的許多人的意見,以獲得不同的觀點和觀點,並確保您不會錯過系統的任何功能。
2.微服務不是組織單位
根據貴公司的組織結構定義微服務是很自然的。如果您正在構建一個單體monolith應用程式,這似乎是一個適當的解決方案。然而,在實現微服務架構時這可能是錯誤的決定。
也許它可以用於銷售部門或客戶服務,但是許多組織擁有單個部門(資訊中心)來處理所有資料庫。因此,為所有資料庫建立一個微服務將導致單點故障。這是微服務的關鍵特徵之一 - 沒有單點故障!
您透過您的服務提供的一些功能可能會延伸到幾個組織部門,也可能需要為單個部門構建許多微伺服器。總而言之,您應該將您的架構服從於您要提供的業務功能,而不是您公司的組織結構。
3.建立適當的團隊結構
切換到完全不同的架構一定會要求公司的管理和監控活動有所變化。前兩個步驟的重點是設計應用程式,為您的終端使用者提供正確的功能。現在是時候確保您對新架構有適當的操作支援。
您將不得不放棄舊的部門結構,並圍繞某些微服務組建團隊。這意味著每個團隊將由具有不同技能的各種成員組成,如系統分析師,UX / UI設計師,後端和前端開發人員等。這樣,團隊將從頭到尾負責他們的專案(微服務) - 從開發和部署到運營,監控和管理。這反過來又會增加他們創造他們自己產品的動力。
團隊的規模將由公司/專案的總體規模決定; 然而,專家認為理想的規模是每隊8-10人。此外,與單體架構不同,微服務架構可讓您在擴充套件業務時擴充套件團隊。
當然,所有的團隊都將積極合作直至整個專案的定稿。這導致我們從這種結構中得到的主要好處是 - 更快將最終產品交付到市場。
4.效能和可靠性是重要的,
切換到微服務架構的全部理念是建立一個比單體架構具有更高效能的最終產品,且更可靠(即具有較低的停機風險),當然也可以更快地投放市場。
將效能作為設計過程的一部分來解決這個問題很重要,以確保能夠及早考慮任何潛在的問題。通常,微服務設計主要集中在功能問題。但是,如果在第一次遭受較大的負載時崩潰或顯著減慢,則該服務將變得無用。每個服務應該有兩個或三個備選機制,它們可以在其他服務內部潛在資源出現故障時繼續執行,如果在可接受的時間範圍內沒有響應,它應該快速迴圈。
提前考慮讓您的服務能夠準備應付更大負載變化是有好處的,有助於您的應用程式迎接真正的挑戰,讓您在市場上具有競爭優勢,這是您決定首先轉向微服務的主要原因!
5.計劃會變更
忽略應用程式的更改是不可能的。開發人員一直新增和刪除功能; 他們改變程式碼,替換應用程式的核心元素,等等。更正確的說,微服務是不斷髮展的。
當您每天多次更新程式碼時,最好接受這種更改也許以後是家常便飯的事情,而不是偶爾為之。一旦認識到這一點,您會意識到從一開始就整合變革所必需的靈活性是很重要的。確保您的應用程式正常工作的一種方法是準備服務API,以便個體微服務可以繼續彼此互動,即使它們發生變化。此外,也應該包括版本控制,以允許新舊服務介面。
另一方面,資料儲存演進更具挑戰性。改變資料表結構以支援新功能傳統上是升級應用程式中最困難的部分,而微伺服器並沒有使其更容易。NoSQL資料庫的新技術在新增新欄位卻不會中斷現有結構方面表現得更加靈活。如果您期望您的資料儲存技術能夠不斷與時俱進,則應將可演化的資料儲存技術作為微服務設計工作的一部分。
總之,正確準備向微服務架構過渡是整個專案成功的關鍵因素。只有仔細規劃,發揮創新的設計思維,以及正確的運營和管理結構,才能獲得微服務提供的所有好處!
一個智者曾經說過,“在業務中使用的任何技術的第一條規則是自動化適用放大現有效率。第二,自動化應用於低效運營將會放大效率低下“。這一理念也適用於微服務。下面闡述實現微服務架構的五個步驟。
1. 從繪圖開始
許多開發人員在開發某個微服務時,會錯誤地直接編碼。這可能是您最大的錯誤。是的,也許你會成功地服務一下; 然而,隨著人數的增加,整個事情將會變得很大。
像需要建立其他產品一樣,該過程必須從設計開始。透過設計,我的意思是與團隊圍繞桌子聚會,並在紙上(或白板)上繪製服務。首先確定您正在構建的應用程式的主要功能。然後,透過自上而下的方法,將其分解成最小的單位。最後,介紹所有這些不同部分的互連性。這些將成為您的微服務的功能。
例如,在書籍評論系統中,主要功能是比較不同的書籍。然而,必須開發許多其他功能,例如建立使用者配置檔案,評級,評論,書籍資料庫等。確定每個功能對於將它們捕獲到微服務中都是至關重要的。
這個過程將持續超過一天時間,需要很多次迭代才能完成。當然,您需要來自不同部門的許多人的意見,以獲得不同的觀點和觀點,並確保您不會錯過系統的任何功能。
2.微服務不是組織單位
根據貴公司的組織結構定義微服務是很自然的。如果您正在構建一個單體monolith應用程式,這似乎是一個適當的解決方案。然而,在實現微服務架構時這可能是錯誤的決定。
也許它可以用於銷售部門或客戶服務,但是許多組織擁有單個部門(資訊中心)來處理所有資料庫。因此,為所有資料庫建立一個微服務將導致單點故障。這是微服務的關鍵特徵之一 - 沒有單點故障!
您透過您的服務提供的一些功能可能會延伸到幾個組織部門,也可能需要為單個部門構建許多微伺服器。總而言之,您應該將您的架構服從於您要提供的業務功能,而不是您公司的組織結構。
3.建立適當的團隊結構
切換到完全不同的架構一定會要求公司的管理和監控活動有所變化。前兩個步驟的重點是設計應用程式,為您的終端使用者提供正確的功能。現在是時候確保您對新架構有適當的操作支援。
您將不得不放棄舊的部門結構,並圍繞某些微服務組建團隊。這意味著每個團隊將由具有不同技能的各種成員組成,如系統分析師,UX / UI設計師,後端和前端開發人員等。這樣,團隊將從頭到尾負責他們的專案(微服務) - 從開發和部署到運營,監控和管理。這反過來又會增加他們創造他們自己產品的動力。
團隊的規模將由公司/專案的總體規模決定; 然而,專家認為理想的規模是每隊8-10人。此外,與單體架構不同,微服務架構可讓您在擴充套件業務時擴充套件團隊。
當然,所有的團隊都將積極合作直至整個專案的定稿。這導致我們從這種結構中得到的主要好處是 - 更快將最終產品交付到市場。
4.效能和可靠性是重要的,
切換到微服務架構的全部理念是建立一個比單體架構具有更高效能的最終產品,且更可靠(即具有較低的停機風險),當然也可以更快地投放市場。
將效能作為設計過程的一部分來解決這個問題很重要,以確保能夠及早考慮任何潛在的問題。通常,微服務設計主要集中在功能問題。但是,如果在第一次遭受較大的負載時崩潰或顯著減慢,則該服務將變得無用。每個服務應該有兩個或三個備選機制,它們可以在其他服務內部潛在資源出現故障時繼續執行,如果在可接受的時間範圍內沒有響應,它應該快速迴圈。
提前考慮讓您的服務能夠準備應付更大負載變化是有好處的,有助於您的應用程式迎接真正的挑戰,讓您在市場上具有競爭優勢,這是您決定首先轉向微服務的主要原因!
5.計劃會變更
忽略應用程式的更改是不可能的。開發人員一直新增和刪除功能; 他們改變程式碼,替換應用程式的核心元素,等等。更正確的說,微服務是不斷髮展的。
當您每天多次更新程式碼時,最好接受這種更改也許以後是家常便飯的事情,而不是偶爾為之。一旦認識到這一點,您會意識到從一開始就整合變革所必需的靈活性是很重要的。確保您的應用程式正常工作的一種方法是準備服務API,以便個體微服務可以繼續彼此互動,即使它們發生變化。此外,也應該包括版本控制,以允許新舊服務介面。
另一方面,資料儲存演進更具挑戰性。改變資料表結構以支援新功能傳統上是升級應用程式中最困難的部分,而微伺服器並沒有使其更容易。NoSQL資料庫的新技術在新增新欄位卻不會中斷現有結構方面表現得更加靈活。如果您期望您的資料儲存技術能夠不斷與時俱進,則應將可演化的資料儲存技術作為微服務設計工作的一部分。
總之,正確準備向微服務架構過渡是整個專案成功的關鍵因素。只有仔細規劃,發揮創新的設計思維,以及正確的運營和管理結構,才能獲得微服務提供的所有好處!
相關文章
- 成功備戰微服務的5個準備步驟微服務
- 業務系統成功微服務化改造的實施步驟微服務
- 五個步驟助企業利用雲端計算獲得成功
- 成功實施CRM流程的5個步驟
- 應用容器化的五個步驟
- 專案的實現:成功的八個步驟(轉)
- 成功實施BPM計劃的5個步驟 - ProServROS
- Masonite 熟悉步驟小記錄 (五、服務容器)
- MongoDB 效能優化五個簡單步驟MongoDB優化
- 單體轉變到微服務之前採取DDD的三個步驟 - Jim Rottinger微服務
- 構建微服務分散式雲架構詳細步驟微服務分散式架構
- 獨立開發人員通向成功的29個小貼士
- 郵件被病毒入侵遵循五個清除步驟
- 企業展廳設計製作的五個流程步驟
- 建立人力資源運營團隊的五個步驟
- 五個步驟幫助你更好地處理工資單
- 開發者談論出品一款價值遊戲的五個步驟遊戲
- SSIS中使用事件處理程式的五個步驟(上)JE事件
- SSIS中使用事件處理程式的五個步驟(下)UJ事件
- 切實有效的三個步驟:如何通過劃分有界上下文設計微服務? - Robert Reppel微服務
- 從五個方面入手,保障微服務應用安全微服務
- odoo的學習步驟五:inhert與xpathOdoo
- 構建Spring Cloud微服務分散式雲架構詳細步驟SpringCloud微服務分散式架構
- 門戶專案成功十步驟 (轉)
- 多圖詳解:不停機分庫分表五個步驟
- vnc安裝步驟,4個在Linux下vnc的個安裝步驟VNCLinux
- 微服務(五)nacos配置管理微服務
- 搭建高效雲的七個步驟
- app開發的幾個步驟APP
- oracle啟動的三個步驟Oracle
- Oracle 啟動的三個步驟Oracle
- 新媒體如何學習?五個步驟讓你快速入門!
- 從SpringCloud看一個微服務框架的「五臟六腑」SpringGCCloud微服務框架
- 簡單幾步使用Dropwizard實現一個RESTful微服務REST微服務
- 維護伺服器的五大步驟伺服器
- 商業與IT專案聯合的五步驟(轉)
- 資料創造價值:個性化服務提升收入的5個步驟
- IT運維服務管理的實施步驟運維