Zalando從一體性架構轉變為微服務的歷程

jopen 8年前發布 | 11K 次閱讀 微服務

業界最負盛名的 微服務 大會 Microxchg 2016 上周于德國柏林舉辦。來自 ZalandoRodrigue Schaefer 為聽眾進行了一場演講,Zalando是一家在歐洲處于領先地位的時尚品牌科技公司,在總共上萬名員工之中有一千多名是技術工作者。Rodrigue在演講中講述了該公司如何將他們的系統從一個一體性的架構遷移至微服務的過程。

該系統原先的一體性應用是由Java、Spring及Postgres等技術所構建的,代碼非常臃腫,并且充斥著大量的依賴,由此引起了許多協作方面的問題,最終造成了開發周期的逐漸緩慢。隨著團隊規模的擴大,bug的比重也隨之上升。為了鞏固現有的系統而引入了許多僵化的流程,導致創新工作難以開展。此外,由于使用的技術棧有些“陳舊”,也造成了招聘進度的緩慢,并且增加了招聘工作的困難。

公司終于意識到他們應該給予團隊充分的信任,而不是強行控制,這意味著每個團隊都能夠按照自身的技術、以及能夠從其他部門那里所獲得的幫助等條件來選擇最適合自己的技術棧與工具。微服務的遷移工作目前已經開展了9個月,技術上的變化包括使用 AWS 進行設置、用 Docker 進行部署以及用 AppdynamicsZmon 進行監控,整個遷移過程已經完成了90%。

對于這樣一個大型公司來說,一旦將整個系統都構建在微服務架構上,就必須做好這200多個微服務隨時可能發生故障的準備。開發者對于服務要承擔起端到端的職責,從DevOps到QA,直至部署過程。每個團隊對于其他團隊來說都必須表現為一種交付服務的 SaaS 平臺,即使對于內部服務也一樣。API優先的概念則意味著全部70多個團隊必須對于API規則保持一致。實現以上目標離不開制訂各種規則的主體文檔、充分的同行審查、以及對于業務實體的一致的理解。

至于在合規性與安全性方面,Zalando遵循了 四眼原則 ,并大量應用了審查記錄跟蹤的做法,以確保每個變更都可以追溯到具體的代碼提交者。

新的系統不允許在不同的微服務之間使用共享的庫,因此每個團隊都必須實現開源,并遵循公司所建立的規則。最后,跨多個團隊的測試服務是由一個跨職能的業務促進單位所實現的。

本次演講的視頻可以在 油Tube 上觀看。

查看英文原文: From Monolith to Microservices, Zalando's Journey

來自: http://www.infoq.com/cn/news/2016/02/Monolith-Microservices-Zalando

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!