《刷爆硅谷的四條微服務軍規》要點：
本文介紹了刷爆硅谷的四條微服務軍規，希望對您有用。如果有疑問，可以聯系我們。

當下,微服務是一個炙手可熱的跨時代架構.跟進這個新趨勢,就意味著你得處理舊應用.尤其在大型組織,雞蛋不會只放在一種架構籃子里.

企業對微服務的興趣漸漸高漲,就好像技術行業的任何正向趨勢.話說到這里,其實我想說更重要的是：請保持對事物前景的透視.雖然微服務已經是“今天的事”,但是你不能只針對這個特定的趨勢做優化.除非你是一個小初創公司,實在沒有富余資源來做投入,否則可能要在以后支持成本更高的混合流程.

微服務最大亮點之一：不用局限在單一的發布周期來對系統一個或多個部分打補丁做優化,也不必把所有內容都部署在一起.如果你想優化一段代碼或糾正錯誤,就像在用單片應用程序那樣,不必等到下一個發布周期.

貌似看起來很高端,對不對?

然而,微服務方法并不是所有軟件開發和交付的靈丹妙藥.除非你有點厲害,對基本所有的問題了如指掌,否則光是報錯就足夠讓你懷疑人生.

下面是我給到的四點建議,希望能幫你避開大坑,用好微服務.

1. 代碼之前請先分解數據

用微服務,你把整體應用分成不同服務以便完成不同任務.電商類應用就是個方便貫徹微服務拆分思想的好例子：用戶登錄,瀏覽產品,看到建議(詳情、評價等),添加購物車、下單、付款.

如果計劃將現有單片應用遷移成微服務體系結構,則需要對系統以及所有服務如何對接與交互有深入的了解,避免分解過程中誤判而做了無用功.要知道,你對數據庫模式做出的決定,無論是要為每個服務設置單獨的數據庫,還是對每個服務設置專用表 ,甚至使用外鍵執行的操作,都會對開銷、總體和成本產生直接影響.

所以這塊我的建議是：分解代碼之前,先分解數據.

2. 還不是大巨人,那就先做小巨人

如果你的微服務改造從一張白紙開始,從一個空白新應用的一小塊開始.首先,你得弄清它涉及的域的樣子以及存在什么類型的數據關系?你在處理事務數據還是關系數據?這些答案將對數據結構產生很大影響.

對于微服務,大多數從業者需要更好地自動化部署管道,從代碼檢入到生產,并且更好地監控環境.你可能看到某個服務有個問題,但很可能實際上是另一個問題在上游的癥狀.在這種情況下,就需要有自動化過程來回滾動服務,或者說在新舊版本之間做切換.

在將應用程序重構到微服務之前,得先了解依賴關系.

3. 注意服務間的通信

服務虛擬化和服務間通信也會導致大問題.微服務一個重要的考量標準是擁有定義良好的公共API,方便探查以及每個微服務做交互.它不care開發人員是否用了REST、HTTP或JSON,而更在于知道它們如何用協議來啟用強大的服務間通信.畢竟如果服務之間的呼叫由于接口設計不當而延遲或中斷,那這故事說起來可就長了.

微服務通常傾向于部署在容器中,因為容器提供隔離,容易設置或刪除,并且只運行一個進程.它們還具有比虛擬機更小的占用空間,因此資源利用率具有相對顯著的差異.

但是如果你有100個服務在100個容器中運行,你就要從運營和管理角度看待事物.首先部署會變得更復雜,而且諸如監視,日志記錄和修復動作會變得越來越重要.

4. 做一把好菜刀的充分條件

俗話說,好鋼用在刀刃上.改造應用,粗淺技術執行起來肯定困難重重,你要確保的是,既然想做一把好菜刀,那你就得有好鋼好手藝.

微服務允許你為每個服務選擇完全不同的技術棧.你可以用Java做這個微服務,用PHP做那個微服務,這個用靜態內容,那個用Apache…隨便你,微服務允許你這樣選擇.也就是說,你就能以更小,更獨立的團隊來處理單個服務.只要分解得當,理論上你的IT管理能力永遠足夠你所能接手的項目.每個團隊可以在獨立發布的生命周期上工作,不會受到分發影響.

大規模運行容器和微服務還需要許多目前在組織中還沒普及開的多學科技能,它和曾經的單一應用開發思維完全不同.在技術和文化層面,熟悉DevOps和持續交付的最佳實踐非常重要.

正好,我們本就應該抱著“活到老學到老”的積極態度面對這個繽紛的世界,對吧?

原文來自微信公眾號：DevOps研究院

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4303.html