軟件開發(fā)并不是一個由定義和執(zhí)行組成的線性過程，而是一個演化過程，在開發(fā)團隊真正明白手頭的問題之前，需要經(jīng)歷與客戶溝通憋肖、向客戶學(xué)習(xí)和向客戶交付的數(shù)次迭代。
使用傳統(tǒng)的瀑布方法面臨的挑戰(zhàn)在于婚苹，許多時候岸更，這些項目的交付的軟件制品粒度具有以下特點：

• 緊耦合的
• 有漏洞的
• 單體的

基于微服務(wù)的構(gòu)架采用不同的方法來交付功能。具體來說膊升，基于微服務(wù)的構(gòu)架具有以下特點：

• 有約束的——微服務(wù)具有范圍有限的單一職責(zé)集怎炊。微服務(wù)遵循UNIX的理念，即應(yīng)用程序是服務(wù)的合集用僧，每個服務(wù)只做一件事结胀，并只做好一件事
• 松耦合的——基于微服務(wù)的應(yīng)用程序是小型服務(wù)的集合赞咙，服務(wù)之間使用非專屬調(diào)用協(xié)議（如HTTP和REST）通過非特定實現(xiàn)的接口彼此交互
• 抽象的——微服務(wù)完全擁有自己的數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)源责循。微服務(wù)所擁有的的數(shù)據(jù)只能由該服務(wù)修改
• 獨立的——微服務(wù)應(yīng)用程序中的每一個微服務(wù)可以獨立于應(yīng)用程序中使用的其他服務(wù)進行編譯和部署

為什么這些微服務(wù)構(gòu)架屬性對基于云的開發(fā)很重要？基于云的應(yīng)用程序通常有以下特點：

• 擁有龐大而多樣化的用戶群
• 極高的運行時間要求
• 不均勻的容量需求

構(gòu)建一個成功的微服務(wù)架構(gòu)的過程需要結(jié)合軟件開發(fā)組織內(nèi)多個人的視角攀操。

• 架構(gòu)師——架構(gòu)師的工作是看到大局院仿，了解應(yīng)用程序如何分為單個微服務(wù)，以及微服務(wù)如何交互以交付解決方案
• 軟件開發(fā)人員——軟件開發(fā)人員編寫代碼并詳細了解如何將編程語言和該語言的開發(fā)框架用于交付微服務(wù)
• DevOps工程師——DevOps工程師不僅為生產(chǎn)環(huán)境而且為所有非生產(chǎn)環(huán)境提供服務(wù)部署和管理的智慧

2.1 架構(gòu)師的故事：設(shè)計微服務(wù)架構(gòu)

架構(gòu)師在軟件項目中的作用是提供待解決問題的工作模型速和。架構(gòu)師的工作是提供腳手架歹垫，開發(fā)人員根據(jù)這些腳手架構(gòu)建他們的代碼，使應(yīng)用程序所有部件都組合在一起颠放。
在構(gòu)建微服務(wù)架構(gòu)時排惨，關(guān)注以下3個關(guān)鍵任務(wù)：
（1）分解業(yè)務(wù)問題
（2）建立服務(wù)粒度
（3）定義服務(wù)接口

2.1.1 分解業(yè)務(wù)問題

架構(gòu)師將業(yè)務(wù)問題分解成代表離散活動領(lǐng)域的塊。這些塊封裝了與業(yè)務(wù)域特定部分相關(guān)聯(lián)的業(yè)務(wù)規(guī)則和數(shù)據(jù)邏輯
分離業(yè)務(wù)領(lǐng)域是一門藝術(shù)碰凶，而不是非黑即白的科學(xué)：
（1）描述業(yè)務(wù)問題暮芭，并聆聽用來描述問題的名詞
（2）注意動詞鹿驼。動詞突出了動作，通常代表問題域的自然輪廓
（3）尋找數(shù)據(jù)內(nèi)聚

2.1.2 建立服務(wù)粒度

構(gòu)建微服務(wù)構(gòu)架時辕宏，粒度的問題很重要畜晰，可以采取用以下思想來確定正確的解決方案。
（1）開始的時候可以讓微服務(wù)涉及的范圍更廣泛一些瑞筐，然后將其重構(gòu)到更小的服務(wù)
（2）重點關(guān)注服務(wù)如何相互交互
（3）隨著對問題域的理解不斷增長凄鼻，服務(wù)的職責(zé)將隨著時間的推移而改變

Tips:糟糕的微服務(wù)的“味道”
如何知道微服務(wù)的劃分是否正確？如果微服務(wù)過于粗粒度聚假，可能會有以下現(xiàn)象：

• 服務(wù)承擔(dān)過多的職責(zé)
• 該服務(wù)正在跨大量表來管理數(shù)據(jù)
• 測試用例太多
  如果微服務(wù)過于細粒度块蚌？
• 問題域的一部分微服務(wù)會像兔子一樣繁殖
• 微服務(wù)彼此之間嚴(yán)重的互相依賴性
• 微服務(wù)成為簡單CRUD（Create，Read膘格，Update匈子，Delete）服務(wù)的集合

2.1.3 相互交流：定義服務(wù)接口

構(gòu)架師需要關(guān)心的最后一部分，是應(yīng)用程序中的微服務(wù)該如何彼此交流闯袒。
在設(shè)計服務(wù)接口時虎敦，可以使用以下指導(dǎo)方針?biāo)伎挤?wù)接口設(shè)計：
（1）擁抱REST理念——REST對服務(wù)的處理方式是將HTTP作為服務(wù)的調(diào)用協(xié)議并使用標(biāo)準(zhǔn)HTTP動詞（GET、PUT政敢、POST和DELETE）其徙。
（2）使用URI來傳達意圖——用作服務(wù)端點的URI應(yīng)描述問題域中的不同資源，并為問題域的資源關(guān)系提供一種基本機制
（3）請求和響應(yīng)使用JSON——JavaScript Object Notation是一個輕量級的數(shù)據(jù)序列化協(xié)議喷户，并且比XML更易于使用
（4）使用HTTP狀態(tài)碼來傳達結(jié)果

2.2 何時不應(yīng)該使用微服務(wù)

首先唾那，讓我們來了解一下構(gòu)建微服務(wù)應(yīng)用程序的考量因素：
（1）構(gòu)建分布式系統(tǒng)的復(fù)雜性
（2）虛擬服務(wù)器/容器散亂
（3）應(yīng)用程序類型
（4）數(shù)據(jù)事物和一致性

2.2.1 構(gòu)建分布式系統(tǒng)的復(fù)雜性

因為微服務(wù)是分布式和細粒度的，所以它們在應(yīng)用程序中引入了一層復(fù)雜性褪尝，而在單體應(yīng)用程序中就不會出現(xiàn)這樣的情況闹获。微服務(wù)需要高度的運維成熟度。除非組織愿意投入高分布式應(yīng)用程序獲得成功所需
的自動化和運維工作（監(jiān)控河哑、伸縮）避诽，否則不要考慮使用微服務(wù)。

2.2.2 服務(wù)器散亂

微服務(wù)最常用的部署模式之一就是在一個服務(wù)器上部署一個微服務(wù)的實例璃谨。即使在云中運行這些服務(wù)的成本較低沙庐，監(jiān)管和監(jiān)控這些服務(wù)器的操作復(fù)雜性也是巨大的。必須對微服務(wù)的靈活性與運行所有這些服務(wù)器的成本進行權(quán)衡佳吞。

2.2.3 應(yīng)用程序的類型

微服務(wù)面向可復(fù)用性拱雏，并且對構(gòu)建需要高度彈性和可伸縮性的大型應(yīng)用程序非常有用。但如果構(gòu)建小型的底扳、部門級的應(yīng)用程序或具有較小用戶群的應(yīng)用程序铸抑，那么搭建一個分布式模型（如微服務(wù)）的復(fù)雜性可能太昂貴了，不值得衷模。

2.2.4 數(shù)據(jù)事物和一致性

如果應(yīng)用程序需要跨多個數(shù)據(jù)源進行復(fù)雜的數(shù)據(jù)聚合或轉(zhuǎn)換鹊汛，那么微服務(wù)的分布式性質(zhì)會讓這項工作變得很困難菇爪。

2.3 開發(fā)人員的故事：用Spring Boot 和Java 構(gòu)建微服務(wù)

（1）構(gòu)建微服務(wù)的基本框架并構(gòu)建應(yīng)用程序的Maven腳本
（2）實現(xiàn)一個Spring 引導(dǎo)類，它將啟動用于微服務(wù)的Spring容器柒昏，并啟動類的所有初始化工作
（3）實現(xiàn)映射端點的Spring Boot 控制器類凳宙，以公開服務(wù)的端點

2.4 DevOps 工程師的故事：構(gòu)建運行時的嚴(yán)謹(jǐn)性

（1）服務(wù)裝配
（2）服務(wù)引導(dǎo)
（3）服務(wù)注冊/發(fā)現(xiàn)
（4）服務(wù)監(jiān)控