微服務遷移：經驗教訓

banq發表於2016-11-24
微服務
“微服務”是最近一段時間在科技領域發生的一個熱門詞彙。 我們最終決定遷移到微服務架構，並希望分享我們為什麼這樣做，我們是如何做到的，以及我們沿途學到的東西。

與大多數Web應用程式一樣，Andela的系統開始是一個“單片整體”軟體架構，包含幾個Web應用程式，每個都有自己的資料庫並負責業務功能。 例如，我們構建了不同的網路應用程式來管理申請人的招聘，選擇，學習成績評估和技能的掌握，這對開發世界級開發人員都至關重要。

隨著我們的應用程式套件的增長，我們遇到三個主要挑戰：
1.在應用程式中有很多重複的業務邏輯。
2.跨應用程式連線資料有問題。
3.不斷增長單片程式碼庫導致產品交付速度較慢。

以前我們構建獨立的單片應用程式是為滿足特定的業務需求，而不是為了實現資料連線應用的生態系統，而後者越來越符合我們的業務運營方式。

很明顯，為了擴充套件，我們需要重新思考我們的軟體架構。在研究不同型別的架構，我們碰到這個部落格帖子nginx ，它推動我們向微服務努力方向。在確定了為什麼微服務將有助於解決我們的挑戰以後，我們決定遷移並開始旅程。

執行
我們首先學習儘可能多的微服務：它們帶來什麼，他們提出了什麼挑戰，以及它們可能對我們的團隊結構和敏捷過程產生的影響。 我們任命Ikem Okonkwo領導這個研究，並領導一個初始有五個開發人員的核心團隊，於是就開始了。他們的研究結果及提出的設計考慮都發表了部落格文章 。一旦我們對調查結果感到滿意，我們開始合併在一起執行計劃。

核心團隊起初是建立我們新的基礎設施，創造了不同的語言微服務模板，建立我們的託管服務（我們離開Heroku搬到到谷歌雲），設定Kafka卡夫卡 （分散式流媒體平臺），設定如何管理我們的伺服器和叢集（ Kubernetes ），並建立持續整合（ ConcourseCI ）。

一旦我們的最低基礎設施需求到位，所有的功能團隊開始將我們的產品遷移到微服務。結果，在六個月的時間裡，我們將五個關鍵的單片系統解耦到35個微服務，前端應用程式透過API閘道器與後端系統互動。 這項工作涉及15名工程師努力工作，以改善我們的平臺。

得到教訓
執行遷移並不是在公園裡散步。我們在路上犯了一些錯誤，雖然幸運的是我們能夠吸取學習了教訓。 這裡有一些在開始遷移之前我們考慮過的事情：

1.學習曲線 ：從建立大應用單元過渡到相對於小的，獨立釋出的單元。這一點很重要，因為構建分散式系統會影響團隊結構，以及它們如何溝通以完成工作。

2.UUID：使用單片系統透過自動遞增的工作得夠好，但在分散式架構中，最終會碰到衝突。UUID允許我們跟蹤不同的業務邏輯並跨生態系統連線它們。

3.入門套件 ：樣板程式碼必須包含開發和部署新的微服務的所有的一切。入門工具包特別有助於加快新開發人員的開發和入職。

4.自動化 ：一個連續的遞交流程和自動化的環境設定，能夠幫助我們的工程師能高度自主地編寫，測試和遞交程式碼。

5.快速完成 ：當我們遷移平臺時，相對現有程式碼庫功能開發的進度好像一場比賽。遷移需要比其程式碼庫本身開放更快地推進。 必須有一支強大的工程師團隊，能夠快速，快速地完成遷移。

儘管我們面臨各種挑戰，移民還是成功得，我們相信我們做出了正確的決定。我們將繼續利用我們的學習，改進我們的平臺和軟體開發過程。我們現在比以往任何時候都更有信心，我們有能力快速迭代產品，為業務提供一致的價值。


Microservices Migration: Lessons Learned – Technol

相關文章