微服務架構師的職責——《微服務設計讀書筆記》

    系列文章目錄：

    《微服務設計》讀書筆記大綱

 

如何定義架構師

        架構師從英文單詞Architect翻譯而來，在英文中，Architect原來的意思是「建築師」。做者吐槽英文中架構師與傳統的建築師單詞相同，但實際的工做性質並不相同，以至於在英文的語境中會形成理解上的差別。

      傳統的建築師在設計建築時要求極端地精確，在正式施工以前會進行完整的論證、設計、計劃等，不容許出現任何差錯；而軟件架構師則地面對的問題更加不可測，軟件在使用的過程當中會面臨大量的需求變動，甚至在發佈至正式環境後仍然不斷演化。

      所以軟件架構師必需要改變那種一開始就要設計出完美產品的想法，相反，咱們應該設計出一個合理的框架，在這個框架中慢慢地演化出正確的系統。這就像城市規劃師同樣，他的職責是優化城鎮佈局，使其易於現有居民生活， 同時也會考慮一些將來的變化，如劃分工業區和居民區，建在工業區的民居是不容許的，居民區的污水處理廠也是不容許的。城市就在這樣的大原則下逐步演化。

      將來的變化很難預見，因此與其對全部變化的可能性進行預測，不如作一個容許變化的計劃，爲此，應該：專一在大方法向，避免對全部事件作過於詳盡的設計，只在有限的狀況下參與到很是具體的細節實現中來，要保證系統不但可以知足當前的需求，還能應對未來的變化。於是，咱們更願意把架構師叫成演化式架構師。

 

演化式架構師的職責

      1.關心服務之間的事務，多於關注服務內部發生的事情

      這並不意味着服務內部的徹底自治，這要視狀況而定，若是整個團隊採用了10種不一樣的技術棧，可能意味着團隊的學習成本更高；或者每一個服務暴露出來的接口標準都不一致，這將形成災難。最低的要求是花時間跟每一個服務團隊在一塊兒工做。

      2.讓系統設計原則服務於最大目標，讓實踐來鞏固原則

      假如公司的目標是：快速佔領東南亞新市場，那麼你的原則可能就是要求服務必須能方便地部署到相應的國家，在實踐層面，咱們可能會尋找能提供全球化的雲廠商來實現咱們的需求。

原則與實戰有時難以區分，但只要把握：重要的原則用來指導系統的演化，同時也要有一些細節來指導如何實現這些原則，就能夠了。

      3.全局掌控微服務的狀態

      必須全局掌握微服務的健康狀態，將這些狀態信息進行統一管理。

      要全局掌握微服務的安全性，不能讓一個異常的服務毀了整個系統，所以每一個服務必須很好地應對其餘服務的錯誤請求。

      4.代碼治理

      提供最佳實踐範例和代碼模板來保證質量，提供統一的服務來保證效率，在DRY中尋求平衡。

      5.技術負債

      有時爲了服務於最大目標，在短期內可能會忽略一些原則和最佳實踐，雖然這短時間能帶來一些利益，但長期來年進要付出代價的。

      不光走捷徑會引入技術負債，有時系統的目標發生改變也會引用技術債務。

      架構師應能提供一些溫和的指導，而後讓團隊自行決定如何償還這些技術負債。

      6.團隊領導

      不要老是施加你的影響力，與各個服務團隊一塊兒工做，即便時間不那麼多，從而瞭解所作的決定對團隊形成的影響。能夠從各服務團隊抽一我的出來造成一個團隊治理小組。

 

參考

      《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）