第一周

云計算

什么是云計算

云計算是一種模式，該模式允許用戶通過無所不在的、便捷的、按需獲得的網絡，接入到一個可動態配置的共享計算資源池（其中包括網絡設備、服務器、存儲、應用以及業務），并且以最小的管理代價或業務交互復雜度即可實現這些可配置計算資源的快速發放與發布。

Saas軟件即服務面臨的挑戰和它的適用性

挑戰一：轉換成本高。解決方案是提升服務質量，增強客戶滿意度。

挑戰二：有限的靈活性。解決方案是提供應用程序交換平臺，提供可定制化服務。

挑戰三：安全性和隱私性。解決方案是盡可能謹慎并更加專業化。

SaaS的適用性：

1、企業軟件應用

• 執行業務功能
• 組織內部和外部信息
• 在內部和外部用戶之間共享數據
• 適用于Saas模型的最標準類型的軟件
• 示例：Saleforce.com CRM應用?Siebel On-demand 程序

2、單用戶軟件應用

• 組織個人信息
• 在用戶自己的本地計算機上運行
• 一次只服務于一個用戶
• 不適用于Saas模型
  • 數據安全問題
  • 網絡性能問題
• 示例：Microsoft辦公套件

3、基礎設施軟件

• 作為大多數其他企業軟件應用的基礎
• 不適用于Saas模型
  • 需要在本地安裝
  • 形成運行其他應用程序的基礎
• 示例：Window XP、Oracle數據庫

4、嵌入式軟件

• 嵌入式系統軟件組件
• 支持硬件設備的功能
• 不適用于Saas模型
  • 嵌入式軟硬件結合在一起，密不可分。
• 示例：嵌入ATM機、手機、路由器、醫療設備等的軟件

?

PaaS的概念

PaaS（平臺即服務）是一個計算平臺，它使得用戶能夠快速、方便地創建web應用，并且無需擔心維護下層軟件。其基本特征包括：在相同的集成開發環境中用來開發、測試、部署、托管和維護的應用;基于web的用戶界面來創建工具，可用于創建、修改、測試和部署不同的UI場景；多租戶架構，可使多個并發用戶使用相同的開發應用；內置部署軟件的可擴展性，包括負載均衡和故障轉移；通過公共標準集成web服務和數據庫；支持開發團隊協作，包括一些PaaS解決方案以及項目規劃、溝通工具等。

國內外著名PaaS提供者包括Google App Engine、Microsoft Azure、百度云等

IaaS的概念

IaaS(基礎設施即服務)以服務模式提供計算、存儲、網絡等基礎設施資源給用戶。傳統方式下企業需要去買物理服務器、存儲等硬件來承載本地應用，讓企業業務運行起來。通過IaaS，企業可將硬件外包給IaaS供應商，供應商會提供可支撐企業應用的服務器，存儲和網絡硬件及虛擬化軟件，對上層業務提供虛擬機或其他基礎設施資源。主流的IaaS供應商包括Amazon，Microsoft，VMWare，阿里、騰訊等

AMI（Amazon Machine Images）

AMI是一種使用亞馬遜云計算服務時創建的機器鏡像，機器鏡像中包括操作系統、應用程序和配置設置。

通過AMI可以運行多個實例，這些實例是AMI的副本，每個實例類型提供不同的計算和內存設施。

Hadoop

Hadoop是一個由apache基金會所開發的分布式系統基礎架構，用戶可以在不了解分布式底層細節的情況下，開發分布式程序，Hadoop的使用和流行使人們可以充分利用集群的能力進行高速運算和存儲。

Hadoop各組件：

HBase（分布式列存數據庫）、Zookeeper（分布式協作服務）、Sqoop（數據同步工具）、Hive（數據倉庫工具）、Pig（數據流系統）、Mahout（數據挖掘算法庫）、Flume（日志收集工具）、Yarn（資源管理器）

DevOps介紹

DevOps 是一個完整的面向IT運維的工作流，以 IT 自動化以及持續集成（CI）、持續部署（CD）為基礎，來優化程式開發、測試、系統運維等所有環節。

SOA面向服務架構相關概念，微服務概念

面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）進行拆分，并通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。

微服務是指開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個服務器上。微服務也指一種種松耦合的、有一定的有界上下文的面向服務架構。也就是說，如果每個服務都要同時修改，那么它們就不是微服務，因為它們緊耦合在一起；如果你需要掌握一個服務太多的上下文場景使用條件，那么它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。

相對于單體架構和SOA，它的主要特點是組件化、松耦合、自治、去中心化，體現在以下幾個方面：

• 一組小的服務?

• 獨立部署運行和擴展?

• 獨立開發和演化?

• 獨立團隊和自治?

第二周

敏捷

敏捷是一組用于軟件產品開發的實踐、價值和原則。

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。它不是一門技術，它是一種開發方法，也就是一種軟件開發的流程，它會指導我們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人；它采用的是迭代式開發。

?

為什么要用敏捷開發：敏捷使軟件產品更好地響應客戶需求，同時可以有效節省精力和資金。

傳統的開發模型可能會增加客戶的成本，原因如下：

1、新技術不斷引進。

2、新玩家進入市場，

3、增加了新的要求

4、“小即美”

5、傾聽顧客的需求，能降低被更小、更靈活的競爭對手擊敗的風險。

6、任何有助于降低維護成本的東西都有助于項目實現

?

敏捷開發和傳統開發對比：

敏捷軟件開發與傳統開發方法相比具有很大的不同，其特點是適應性而不是預測性，強調溝通和反饋，開發團隊不僅包括開發人員，還包括管理人員和客戶。它鼓勵團隊成員的相互交流通過反饋機制盡早糾正軟件中的錯誤，提高開發效率，同時為需求的調整提供更多機會，保證軟件向正確的方向發展。

傳統軟件開發如瀑布模型強調預見性，嚴格遵循計劃、分析、設計、編碼、測試和維護等幾個階段。瀑布模型開發各階段間具有嚴格的順序性和依賴性，必須等到前一階段的工作結束后才能開始下一階段的工作，前一階段的輸出文檔是后一階段的輸入文檔，只有前一階段的輸出文檔完全正確，后一階段才能獲得正確的結果。

?

敏捷開發的原則：

1、最優先考慮的是通過早期和連續交付有價值的軟件來滿足客戶。

2、擁抱變化。敏捷過程利用變化來獲得競爭優勢。

3、頻繁地交付工作，從幾周到幾個月，優先用更短的交付時間。

4、同一個項目的業務人員和開發人員必須在一起工作。

5、圍繞有能力的個人建立項目。給他們需要的環境和支持，信任他們完成工作。

6、向開發團隊傳遞信息最有效的方法是面對面的交談。

7、工作軟件是進度的主要度量。

8、敏捷過程促進可持續發展。贊助商、開發人員和用戶應該能夠無限期地保持恒定的步伐。

9、持續關注技術的卓越性和良好的設計可以提高敏捷性。

10、簡潔是必不可少的。

11、組建團隊實現最好的架構、需求和設計。

12、每隔一段時間，團隊要思考如何變得更加有效，然后相應地進行調整。

?

敏捷方法：scrum

scrum是一種敏捷開發流程，在scrum流程中包含三大角色：

產品負責人（Product Owner）

主要負責確定產品的功能和達到要求的標準，指定軟件的發布日期和交付的內容，同時有權力接受或拒絕開發團隊的工作成果。

流程管理員（Scrum Master）

主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發工作之間的溝通障礙，使得客戶可以直接驅動開發。

開發團隊（Scrum Team）

主要負責軟件產品在Scrum規定流程下進行開發工作，人數控制在5~10人左右，每個成員可能負責不同的技術方面，但要求每成員必須要有很強的自我管理能力，同時具有一定的表達能力；成員可以采用任何工作方式，只要能達到Sprint的目標。

如何進行scrum開發：

1、我們首先需要確定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；

2、Scrum Team根據Product Backlog列表，做工作量的預估和安排；

3、有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間周期是1~4個星期，然后把這個Story進行細化，形成一個Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；

5、在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面匯報你昨天完成了什么，并且向所有成員承諾你今天要完成什么，同時遇到不能解決的問題也可以提出，每個人回答完成后，要走到黑板前更新自己的?Sprint burn down（Sprint燃盡圖）；

6、做到每日集成，也就是每天都要有一個可以成功編譯、并且可以演示的版本；很多人可能還沒有用過自動化的每日集成，其實TFS就有這個功能，它可以支持每次有成員進行簽入操作的時候，在服務器上自動獲取最新版本，然后在服務器中編譯，如果通過則馬上再執行單元測試代碼，如果也全部通過，則將該版本發布，這時一次正式的簽入操作才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；

7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行?Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老板也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；

8、最后就是?Sprint Retrospective?Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結并討論改進的地方，放入下一輪Sprint的產品需求中；

敏捷估算

計劃撲克玩法

1.發牌?
2.拎出一個要估算的功能，PM解釋要求?
3.開發人員根據功能給出自己的估算值，用牌上 的最接近的數字代替，出牌背面朝上（每次一張）?
4.大家同時翻轉牌，差距過大的人給出自己的想法?
5.大家根據剛剛的發言再出牌和翻轉，直到達成一致，該功能的估算結束?
6.重復2~5直至團隊資源耗盡。
?

第三周

scrum

scrum中的迭代方式

1、迭代計劃——為一次迭代創建一個計劃

選擇下一個要交付的內容（按優先級選擇），定義和估計任務，協商交付產品的范圍

2、迭代執行——實現計劃中的項目

處理需求、設計、代碼、集成/構建，并測試計劃中需要的模塊

3、交付迭代的結果——給出demo

步驟1-3將根據發布計劃多次執行

每個周期是一個固定長度的時間盒：

總是按計劃結束每次迭代，即使它不是完整的

（不要說——“我們可以在另外兩天內完成這次迭代的所有工作”）。只需交付并運行下一次迭代計劃會議。

團隊學會了做出好的短期估計——因此，隨著時間的推移，大多數迭代都會如期交付。

scrum角色

scrum小組

scrum板

待辦事項

敏捷使用產品Backlog來管理需求，產品Backlog是一個需求的清單，按照需求的商業價值排序， 高優先級的需求在Backlog的最上層。產品Backlog是一個漸進明細的清單，它有4個主要特點，稱之為DEEP：

• Detailed 合適的詳細程度，高優先級需求更加明細，低優先級的需求粒度更大
• Emergent 涌現式的，需求是慢慢涌現出來的，漸進明細的
• Estimated 經過估算的
• Prioritized/ Ordered 根據商業價值排好順序的

在產品Backlog中，需求的主要表現形式是用戶故事。用戶故事是從用戶的角度對需求的簡短描述。用戶故事是將團隊的焦點從描述、編寫功能需求轉移到討論需求的最佳方式。

用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：

• 角色：誰要使用這個功能。
• 活動：需要完成什么樣的功能。
• 商業價值：為什么需要這個功能，這個功能帶來什么樣的價值。

作為一個<角色>, 我想要<活動>, 以便于<商業價值>。
比如：作為一個網站的普通會員，我期望在我下訂單后，未發貨之前可以取消訂單，這樣對我來說更靈活。

scrum管理工具

https://www.leangoo.com/kanban/board_list

第四周

軟件系統架構演變

1.1 單一應用架構

當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用于簡化增刪改查工作量的數據訪問框架(ORM)是關鍵。

1.2 垂直應用架構

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用于加速前端頁面開發的Web框架(MVC)是關鍵。

1.3 分布式服務架構

當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用于提高業務復用及整合的分布式服務框架(RPC)是關鍵。

1.4 流動計算架構

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基于訪問壓力實時管理集群容量，提高集群利用率。此時，用于提高機器利用率的資源調度和治理中心(SOA)是關鍵。

?

一、微服務介紹

1. 什么是微服務

? ? ? 微服務得從兩個方面去理解，什么是"微"、什么是"服務"， 微 狹義來講就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來 只需要2個披薩就夠了 ）。 而所謂服務，一定要區別于系統，服務一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。

2. 微服務由來

? ? 微服務最早由Martin Fowler與James Lewis于2014年共同提出，微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑，每個服務運行在自己的進程中，并使用輕量級機制通信，通常是HTTP API，這些服務基于業務能力構建，并能夠通過自動化部署機制來獨立部署，這些服務使用不同的編程語言實現，以及不同數據存儲技術，并保持最低限度的集中式管理。

3. 為什么需要微服務？

? ? ? ? 在傳統的IT行業軟件大多都是各種獨立系統的堆砌，這些系統的問題總結來說就是擴展性差，可靠性不高，維護成本高。到后面引入了SOA服務化，但是，由于 SOA 早期均使用了總線模式，這種總線模式是與某種技術棧強綁定的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間。最終 SOA 看起來很美，但卻成為了企業級奢侈品，中小公司都望而生畏。

3.1 最期的單體架構帶來的問題

單體架構在規模比較小的情況下工作情況良好，但是隨著系統規模的擴大，它暴露出來的問題也越來越多，主要有以下幾點：

1.復雜性逐漸變高

比如有的項目有幾十萬行代碼，各個模塊之間區別比較模糊，邏輯比較混亂，代碼越多復雜性越高，越難解決遇到的問題。

2.技術債務逐漸上升

公司的人員流動是再正常不過的事情，有的員工在離職之前，疏于代碼質量的自我管束，導致留下來很多坑，由于單體項目代碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多。

3.部署速度逐漸變慢

這個就很好理解了，單體架構模塊非常多，代碼量非常龐大，導致部署項目所花費的時間越來越多，曾經有的項目啟動就要一二十分鐘，這是多么恐怖的事情啊，啟動幾次項目一天的時間就過去了，留給開發者開發的時間就非常少了。

4.阻礙技術創新

比如以前的某個項目使用struts2寫的，由于各個模塊之間有著千絲萬縷的聯系，代碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個項目將是非常困難的，付出的成本將非常大，所以更多的時候公司不得不硬著頭皮繼續使用老的struts架構，這就阻礙了技術的創新。

5.無法按需伸縮

比如說電影模塊是CPU密集型的模塊，而訂單模塊是IO密集型的模塊，假如我們要提升訂單模塊的性能，比如加大內存、增加硬盤，但是由于所有的模塊都在一個架構下，因此我們在擴展訂單模塊的性能時不得不考慮其它模塊的因素，因為我們不能因為擴展某個模塊的性能而損害其它模塊的性能，從而無法按需進行伸縮。

3.2 微服務與單體架構區別

1、單體架構所有的模塊全都耦合在一塊，代碼量大，維護困難，微服務每個模塊就相當于一個單獨的項目，代碼量明顯減少，遇到問題也相對來說比較好解決。

2、單體架構所有的模塊都共用一個數據庫，存儲方式比較單一，微服務每個模塊都可以使用不同的存儲方式（比如有的用redis，有的用mysql等），數據庫也是單個模塊對應自己的數據庫。

3、單體架構所有的模塊開發所使用的技術一樣，微服務每個模塊都可以使用不同的開發技術，開發模式更靈活。

3.3 微服務與SOA區別

微服務，從本質意義上看，還是 SOA 架構。但內涵有所不同，微服務并不綁定某種特殊的技術，在一個微服務的系統中，可以有 Java 編寫的服務，也可以有 Python編寫的服務，他們是靠Restful架構風格統一成一個系統的。所以微服務本身與具體技術實現無關，擴展性強。

4. 微服務本質

1、微服務，關鍵其實不僅僅是微服務本身，而是系統要提供一套基礎的架構，這種架構使得微服務可以獨立的部署、運行、升級，不僅如此，這個系統架構還讓微服務與微服務之間在結構上“松耦合”，而在功能上則表現為一個統一的整體。這種所謂的“統一的整體”表現出來的是統一風格的界面，統一的權限管理，統一的安全策略，統一的上線過程，統一的日志和審計方法，統一的調度方式，統一的訪問入口等等。

2、微服務的目的是有效的拆分應用，實現敏捷開發和部署 。

3、微服務提倡的理念團隊間應該是 inter-operate, not integrate 。inter-operate是定義好系統的邊界和接口，在一個團隊內全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能降低。

5. 什么樣的項目適合微服務

? ?微服務可以按照業務功能本身的獨立性來劃分，如果系統提供的業務是非常底層的，如：操作系統內核、存儲系統、網絡系統、數據庫系統等等，這類系統都偏底層，功能和功能之間有著緊密的配合關系，如果強制拆分為較小的服務單元，會讓集成工作量急劇上升，并且這種人為的切割無法帶來業務上的真正的隔離，所以無法做到獨立部署和運行，也就不適合做成微服務了。

能不能做成微服務，取決于四個要素：

小：微服務體積小，2 pizza 團隊。

獨：能夠獨立的部署和運行。

輕：使用輕量級的通信機制和架構。

松：為服務之間是松耦合的。

微服務折分與設計

1、從單體式結構轉向微服務架構中會持續碰到服務邊界劃分的問題：比如，我們有user 服務來提供用戶的基礎信息，那么用戶的頭像和圖片等是應該單獨劃分為一個新的service更好還是應該合并到user服務里呢？如果服務的粒度劃分的過粗，那就回到了單體式的老路；如果過細，那服務間調用的開銷就變得不可忽視了，管理難度也會指數級增加。目前為止還沒有一個可以稱之為服務邊界劃分的標準，只能根據不同的業務系統加以調節

2、拆分的大原則是當一塊業務不依賴或極少依賴其它服務，有獨立的業務語義，為超過2個的其他服務或客戶端提供數據，那么它就應該被拆分成一個獨立的服務模塊。

6.1 微服務設計原則

單一職責原則

意思是每個微服務只需要實現自己的業務邏輯就可以了，比如訂單管理模塊，它只需要處理訂單的業務邏輯就可以了，其它的不必考慮。

服務自治原則

意思是每個微服務從開發、測試、運維等都是獨立的，包括存儲的數據庫也都是獨立的，自己就有一套完整的流程，我們完全可以把它當成一個項目來對待。不必依賴于其它模塊。

輕量級通信原則

首先是通信的語言非常的輕量，第二，該通信方式需要是跨語言、跨平臺的，之所以要跨平臺、跨語言就是為了讓每個微服務都有足夠的獨立性，可以不受技術的鉗制。

接口明確原則

由于微服務之間可能存在著調用關系，為了盡量避免以后由于某個微服務的接口變化而導致其它微服務都做調整，在設計之初就要考慮到所有情況，讓接口盡量做的更通用，更靈活，從而盡量避免其它模塊也做調整。

7. 微服務優勢與缺點

7.1 特性

1、每個微服務可獨立運行在自己的進程里；

2、一系列獨立運行的微服務共同構建起了整個系統；

3、每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能，比如：訂單管理，用戶管理等；

4、微服務之間通過一些輕量級的通信機制進行通信，例如通過REST API或者RPC的方式進行調用。

7.2 特點

易于開發和維護

由于微服務單個模塊就相當于一個項目，開發這個模塊我們就只需關心這個模塊的邏輯即可，代碼量和邏輯復雜度都會降低，從而易于開發和維護。

啟動較快

這是相對單個微服務來講的，相比于啟動單體架構的整個項目，啟動某個模塊的服務速度明顯是要快很多的。

局部修改容易部署

在開發中發現了一個問題，如果是單體架構的話，我們就需要重新發布并啟動整個項目，非常耗時間，但是微服務則不同，哪個模塊出現了bug我們只需要解決那個模塊的bug就可以了，解決完bug之后，我們只需要重啟這個模塊的服務即可，部署相對簡單，不必重啟整個項目從而大大節約時間。

技術棧不受限

比如訂單微服務和電影微服務原來都是用java寫的，現在我們想把電影微服務改成nodeJs技術，這是完全可以的，而且由于所關注的只是電影的邏輯而已，因此技術更換的成本也就會少很多。

按需伸縮

我們上面說了單體架構在想擴展某個模塊的性能時不得不考慮到其它模塊的性能會不會受影響，對于我們微服務來講，完全不是問題，電影模塊通過什么方式來提升性能不必考慮其它模塊的情況。

7.3 缺點

運維要求較高

對于單體架構來講，我們只需要維護好這一個項目就可以了，但是對于微服務架構來講，由于項目是由多個微服務構成的，每個模塊出現問題都會造成整個項目運行出現異常，想要知道是哪個模塊造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。

分布式的復雜性

對于單體架構來講，我們可以不使用分布式，但是對于微服務架構來說，分布式幾乎是必會用的技術，由于分布式本身的復雜性，導致微服務架構也變得復雜起來。

接口調整成本高

比如，用戶微服務是要被訂單微服務和電影微服務所調用的，一旦用戶微服務的接口發生大的變動，那么所有依賴它的微服務都要做相應的調整，由于微服務可能非常多，那么調整接口所造成的成本將會明顯提高。

重復勞動

對于單體架構來講，如果某段業務被多個模塊所共同使用，我們便可以抽象成一個工具類，被所有模塊直接調用，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接調用的，從而我們便不得不在每個微服務上都建這么一個工具類，從而導致代碼的重復。

8. 微服務開發框架

目前微服務的開發框架，最常用的有以下四個：

Spring Cloud：http://projects.spring.io/spring-cloud（現在非常流行的微服務架構）

Dubbo：http：//dubbo.io

Dropwizard：http://www.dropwizard.io （關注單個微服務的開發）

Consul、etcd&etc.（微服務的模塊）

無論是Dubbo還是Spring Cloud都只適用于特定的應用場景和開發環境，它們的設計目的并不是為了支持通用性和多語言性。并且它們只是Dev層的框架，缺少DevOps的整體解決方案（這正是微服務架構需要關注的）。而隨之而來的便是Service Mesh的興起。

?

9. Sprint cloud 和 Sprint boot區別

Spring Boot:

旨在簡化創建產品級的Spring應用和服務，簡化了配置文件，使用嵌入式web服務器，含有諸多開箱即用微服務功能，可以和spring cloud聯合部署。

?Spring Cloud：

微服務工具包，為開發者提供了在分布式系統的配置管理、服務發現、斷路器、智能路由、微代理、控制總線等開發工具包。

二、微服務實踐先知

1. 客戶端如何訪問這些服務？（API Gateway）

傳統的開發方式，所有的服務都是本地的，UI可以直接調用，現在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機上的 Java進程了。客戶端UI如何訪問他的？后臺有N個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不服務我們 拆分的理念，特別當前臺是移動應用的時候，通常業務變化的節奏更快。另外，N個小服務的調用也是一個不小的網絡開銷。還有一般微服務在系統內部，通常是無狀態的，用戶登錄信息和權限管理最好有一個統一的地方維護管理（OAuth）。

所以，一般在后臺N個服務和UI之間一般會一個代理或者叫API Gateway，他的作用包括

提供統一服務入口，讓微服務對前臺透明

聚合后臺的服務，節省流量，提升性能

提供安全，過濾，流控等API管理功能

我的理解其實這個API Gateway可以有很多廣義的實現辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的作用是為前臺（通常是移動應用）提供后臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者性能的瓶頸。

2. 服務之間如何通信？（服務調用）

因為所有的微服務都是獨立的Java進程跑在獨立的虛擬機上，所以服務間的通行就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式。

REST（JAX-RS，Spring Boot）

RPC（Thrift, Dubbo）

異步消息調用(Kafka, Notify)

一般同步調用比較簡單，一致性強，但是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個很有意 思的話題。一般REST基于HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要 求，只要封裝了HTTP的SDK就能調用，所以相對使用的廣一些。RPC也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一個的開發規范和統一的服務框架時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。

而異步消息的方式在分布式系統中有特別廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確保消息積壓不會沖垮被調用方，同時能 保證調用方的服務體驗，繼續干自己該干的活，不至于被后臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數據最終一致性；還有就是后臺服務一般要 實現冪等性，因為消息發送出于性能的考慮一般會有重復（保證消息的被收到且僅收到一次對性能是很大的考驗）；最后就是必須引入一個獨立的broker，如 果公司內部沒有技術積累，對broker分布式管理也是一個很大的挑戰。

3. 這么多服務怎么查找？（服務發現）

? ? ?在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增加新的服務節點。服務之間如何相互 感知？服務如何管理？這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過zookeeper等類似技術做服務注冊信息的分布式管理。當 服務上線時，服務提供者將自己的服務信息注冊到ZK（或類似框架），并通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過ZK尋址，根據可定制算法，找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK會發通知給服務客戶端。

客戶端做：優點是架構簡單，擴展靈活，只對服務注冊器依賴。缺點是客戶端要維護所有調用服務的地址，有技術難度，一般大公司都有成熟的內部框架支持，比如Dubbo。?

服務端做：優點是簡單，所有服務對于前臺調用方透明，一般在小公司在云服務上部署的應用采用的比較多。

4. 服務掛了怎么辦？

? ? 分布式最大的特性就是網絡是不可靠 的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障，結局肯定是噩夢。我們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在訪問量上升 時，導致數據庫load彪高，影響了所在應用的性能，從而影響所有調用這個應用服務的前臺應用。所以當我們的系統是由一系列的服務調用鏈組成的時候，我們必須確保任一環節出問題都不至于影響整體鏈路。相應的手段有很多：

重試機制

限流

熔斷機制

負載均衡

降級（本地緩存） 這些方法基本上都很明確通用，就不詳細說明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

5. 微服務需要考慮的問題

API Gateway?? 服務間調用? 服務發現? 服務容錯? 服務部署?? 數據調用

6、微服務的開發生命周期

設計? ?開發? ?觀察? ?依次循環

三、微服務重要部件

1. 微服務基本能力

2. 服務注冊中心

? ? 服務之間需要創建一種服務發現機制，用于幫助服務之間互相感知彼此的存在。服務啟動時會將自身的服務信息注冊到注冊中心，并訂閱自己需要消費的服務。

服務注冊中心是服務發現的核心。它保存了各個可用服務實例的網絡地址（IPAddress和Port）。服務注冊中心必須要有高可用性和實時更新功能。上面提到的 Netflix Eureka 就是一個服務注冊中心。它提供了服務注冊和查詢服務信息的REST API。服務通過使用POST請求注冊自己的IPAddress和Port。每30秒發送一個PUT請求刷新注冊信息。通過DELETE請求注銷服務。客戶端通過GET請求獲取可用的服務實例信息。 Netflix的高可用（Netflix achieves high availability ）是通過在Amazon EC2運行多個實例來實現的,每一個Eureka服務都有一個彈性IP Address。當Eureka服務啟動時，有DNS服務器動態的分配。Eureka客戶端通過查詢 DNS來獲取Eureka的網絡地址（IP Address和Port）。一般情況下，都是返回和客戶端在同一個可用區Eureka服務器地址。 其他能夠作為服務注冊中心的有：

etcd —– 高可用，分布式，強一致性的，key-value，Kubernetes和Cloud Foundry都是使用了etcd

consul —–一個用于discovering和configuring的工具。它提供了允許客戶端注冊和發現服務的API。Consul可以進行服務健康檢查，以確定服務的可用性。

zookeeper —— 在分布式應用中被廣泛使用，高性能的協調服務。 Apache Zookeeper 最初為Hadoop的一個子項目，但現在是一個頂級項目。

2.1 zookeeper服務注冊和發現

簡單來講，zookeeper可以充當一個服務注冊表（Service Registry），讓多個服務提供者形成一個集群，讓服務消費者通過服務注冊表獲取具體的服務訪問地址（ip+端口）去訪問具體的服務提供者。如下圖所示：?

具體來說，zookeeper就是個分布式文件系統，每當一個服務提供者部署后都要將自己的服務注冊到zookeeper的某一路徑上: /{service}/{version}/{ip:port}, 比如我們的HelloWorldService部署到兩臺機器，那么zookeeper上就會創建兩條目錄：分別為/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。

zookeeper提供了“心跳檢測”功能，它會定時向各個服務提供者發送一個請求（實際上建立的是一個 socket 長連接），如果長期沒有響應，服務中心就認為該服務提供者已經“掛了”，并將其剔除，比如100.19.20.02這臺機器如果宕機了，那么zookeeper上的路徑就會只剩/HelloWorldService/1.0.0/100.19.20.01:16888。

服務消費者會去監聽相應路徑（/HelloWorldService/1.0.0），一旦路徑上的數據有任務變化（增加或減少），zookeeper都會通知服務消費方服務提供者地址列表已經發生改變，從而進行更新。

更為重要的是zookeeper 與生俱來的容錯容災能力（比如leader選舉），可以確保服務注冊表的高可用性。

3. 負載均衡

服務高可用的保證手段，為了保證高可用，每一個微服務都需要部署多個服務實例來提供服務。此時客戶端進行服務的負載均衡。

3.1 負載均衡的常見策略

3.1.1 隨機

把來自網絡的請求隨機分配給內部中的多個服務器。

3.1.2 輪詢

每一個來自網絡中的請求，輪流分配給內部的服務器，從1到N然后重新開始。此種負載均衡算法適合服務器組內部的服務器都具有相同的配置并且平均服務請求相對均衡的情況。

3.1.3 加權輪詢

根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重。

3.1.4 IP Hash

這種方式通過生成請求源IP的哈希值，并通過這個哈希值來找到正確的真實服務器。這意味著對于同一主機來說他對應的服務器總是相同。使用這種方式，你不需要保存任何源IP。但是需要注意，這種方式可能導致服務器負載不平衡。

3.1.5 最少連接數

客戶端的每一次請求服務在服務器停留的時間可能會有較大的差異，隨著工作時間加長，如果采用簡單的輪循或隨機均衡算法，每一臺服務器上的連接進程可能會產生極大的不同，并沒有達到真正的負載均衡。最少連接數均衡算法對內部中需負載的每一臺服務器都有一個數據記錄，記錄當前該服務器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的服務器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法適合長時處理的請求服務，如FTP。

4. 容錯

容錯，這個詞的理解，直面意思就是可以容下錯誤，不讓錯誤再次擴張，讓這個錯誤產生的影響在一個固定的邊界之內，“千里之堤毀于蟻穴”我們用容錯的方式就是讓這種蟻穴不要變大。那么我們常見的降級，限流，熔斷器，超時重試等等都是容錯的方法。

在調用服務集群時，如果一個微服務調用異常，如超時，連接異常，網絡異常等，則根據容錯策略進行服務容錯。目前支持的服務容錯策略有快速失敗，失效切換。如果連續失敗多次則直接熔斷，不再發起調用。這樣可以避免一個服務異常拖垮所有依賴于他的服務。

4.1 容錯策略

4.1.1 快速失敗

服務只發起一次待用，失敗立即報錯。通常用于非冪等下性的寫操作

4.1.2 失效切換

服務發起調用，當出現失敗后，重試其他服務器。通常用于讀操作，但重試會帶來更長時間的延遲。重試的次數通常是可以設置的

4.1.3 失敗安全

失敗安全， 當服務調用出現異常時，直接忽略。通常用于寫入日志等操作。

4.1.4 失敗自動恢復

當服務調用出現異常時，記錄失敗請求，定時重發。通常用于消息通知。

4.1.5 forking Cluster

并行調用多個服務器，只要有一個成功，即返回。通常用于實時性較高的讀操作。可以通過forks=n來設置最大并行數。

4.1.6 廣播調用

廣播調用所有提供者，逐個調用，任何一臺失敗則失敗。通常用于通知所有提供者更新緩存或日志等本地資源信息。

5. 熔斷

熔斷技術可以說是一種“智能化的容錯”，當調用滿足失敗次數，失敗比例就會觸發熔斷器打開，有程序自動切斷當前的RPC調用,來防止錯誤進一步擴大。實現一個熔斷器主要是考慮三種模式，關閉，打開，半開。各個狀態的轉換如下圖。

? ?我們在處理異常的時候，要根據具體的業務情況來決定處理方式，比如我們調用商品接口，對方只是臨時做了降級處理，那么作為網關調用就要切到可替換的服務上來執行或者獲取托底數據，給用戶友好提示。還有要區分異常的類型，比如依賴的服務崩潰了，這個可能需要花費比較久的時間來解決。也可能是由于服務器負載臨時過高導致超時。作為熔斷器應該能夠甄別這種異常類型，從而根據具體的錯誤類型調整熔斷策略。增加手動設置，在失敗的服務恢復時間不確定的情況下，管理員可以手動強制切換熔斷狀態。最后，熔斷器的使用場景是調用可能失敗的遠程服務程序或者共享資源。如果是本地緩存本地私有資源，使用熔斷器則會增加系統的額外開銷。還要注意，熔斷器不能作為應用程序中業務邏輯的異常處理替代品。

有一些異常比較頑固，突然發生，無法預測，而且很難恢復，并且還會導致級聯失敗（舉個例子，假設一個服務集群的負載非常高，如果這時候集群的一部分掛掉了，還占了很大一部分資源，整個集群都有可能遭殃）。如果我們這時還是不斷進行重試的話，結果大多都是失敗的。因此，此時我們的應用需要立即進入失敗狀態(fast-fail)，并采取合適的方法進行恢復。

我們可以用狀態機來實現CircuitBreaker，它有以下三種狀態：

關閉( Closed )：默認情況下Circuit Breaker是關閉的，此時允許操作執行。CircuitBreaker內部記錄著最近失敗的次數，如果對應的操作執行失敗，次數就會續一次。如果在某個時間段內，失敗次數（或者失敗比率）達到閾值，CircuitBreaker會轉換到開啟( Open )狀態。在開啟狀態中，Circuit Breaker會啟用一個超時計時器，設這個計時器的目的是給集群相應的時間來恢復故障。當計時器時間到的時候，CircuitBreaker會轉換到半開啟( Half-Open )狀態。

開啟( Open )：在此狀態下，執行對應的操作將會立即失敗并且立即拋出異常。

半開啟( Half-Open )：在此狀態下，Circuit Breaker會允許執行一定數量的操作。如果所有操作全部成功，CircuitBreaker就會假定故障已經恢復，它就會轉換到關閉狀態，并且重置失敗次數。如果其中 任意一次 操作失敗了，Circuit Breaker就會認為故障仍然存在，所以它會轉換到開啟狀態并再次開啟計時器（再給系統一些時間使其從失敗中恢復。

6. 限流和降級

? ? 保證核心服務的穩定性。為了保證核心服務的穩定性，隨著訪問量的不斷增加，需要為系統能夠處理的服務數量設置一個極限閥值，超過這個閥值的請求則直接拒絕。同時，為了保證核心服務的可用，可以對否些非核心服務進行降級，通過限制服務的最大訪問量進行限流，通過管理控制臺對單個微服務進行人工降級

7. SLA

SLA：Service-LevelAgreement的縮寫，意思是服務等級協議。 是關于網絡服務供應商和客戶間的一份合同，其中定義了服務類型、服務質量和客戶付款等術語。 典型的SLA包括以下項目：

分配給客戶的最小帶寬；

客戶帶寬極限；

能同時服務的客戶數目；

在可能影響用戶行為的網絡變化之前的通知安排；

撥入訪問可用性；

運用統計學；

服務供應商支持的最小網絡利用性能，如99.9%有效工作時間或每天最多為1分鐘的停機時間；

各類客戶的流量優先權；

客戶技術支持和服務；

懲罰規定，為服務供應商不能滿足 SLA需求所指定。

8. API網關

? ?這里說的網關是指API網關，直面意思是將所有API調用統一接入到API網關層，有網關層統一接入和輸出。一個網關的基本功能有：統一接入、安全防護、協議適配、流量管控、長短鏈接支持、容錯能力。有了網關之后，各個API服務提供團隊可以專注于自己的的業務邏輯處理，而API網關更專注于安全、流量、路由等問題。

9. 多級緩存

? ? ?最簡單的緩存就是查一次數據庫然后將數據寫入緩存比如redis中并設置過期時間。因為有過期失效因此我們要關注下緩存的穿透率，這個穿透率的計算公式，比如查詢方法queryOrder(調用次數1000/1s)里面嵌套查詢DB方法queryProductFromDb(調用次數300/s)，那么redis的穿透率就是300/1000,在這種使用緩存的方式下，是要重視穿透率的，穿透率大了說明緩存的效果不好。還有一種使用緩存的方式就是將緩存持久化，也就是不設置過期時間，這個就會面臨一個數據更新的問題。一般有兩種辦法，一個是利用時間戳，查詢默認以redis為主，每次設置數據的時候放入一個時間戳，每次讀取數據的時候用系統當前時間和上次設置的這個時間戳做對比，比如超過5分鐘，那么就再查一次數據庫。這樣可以保證redis里面永遠有數據，一般是對DB的一種容錯方法。還有一個就是真正的讓redis做為DB使用。就是圖里面畫的通過訂閱數據庫的binlog通過數據異構系統將數據推送給緩存，同時將將緩存設置為多級。可以通過使用jvmcache作為應用內的一級緩存，一般是體積小，訪問頻率大的更適合這種jvmcache方式，將一套redis作為二級remote緩存，另外最外層三級redis作為持久化緩存。

10. 超時和重試

? ? 超時與重試機制也是容錯的一種方法，凡是發生RPC調用的地方，比如讀取redis，db，mq等，因為網絡故障或者是所依賴的服務故障，長時間不能返回結果，就會導致線程增加，加大cpu負載，甚至導致雪崩。所以對每一個RPC調用都要設置超時時間。對于強依賴RPC調用資源的情況，還要有重試機制，但是重試的次數建議1-2次，另外如果有重試，那么超時時間就要相應的調小，比如重試1次，那么一共是發生2次調用。如果超時時間配置的是2s，那么客戶端就要等待4s才能返回。因此重試+超時的方式，超時時間要調小。這里也再談一下一次PRC調用的時間都消耗在哪些環節，一次正常的調用統計的耗時主要包括： ①調用端RPC框架執行時間 + ②網絡發送時間 + ③服務端RPC框架執行時間 + ④服務端業務代碼時間。調用方和服務方都有各自的性能監控，比如調用方tp99是500ms，服務方tp99是100ms，找了網絡組的同事確認網絡沒有問題。那么時間都花在什么地方了呢，兩種原因，客戶端調用方，還有一個原因是網絡發生TCP重傳。所以要注意這兩點。

11. 線程池隔離

? ? ? 在抗量這個環節，Servlet3異步的時候，有提到過線程隔離。線程隔離的之間優勢就是防止級聯故障，甚至是雪崩。當網關調用N多個接口服務的時候，我們要對每個接口進行線程隔離。比如，我們有調用訂單、商品、用戶。那么訂單的業務不能夠影響到商品和用戶的請求處理。如果不做線程隔離，當訪問訂單服務出現網絡故障導致延時，線程積壓最終導致整個服務CPU負載滿。就是我們說的服務全部不可用了，有多少機器都會被此刻的請求塞滿。那么有了線程隔離就會使得我們的網關能保證局部問題不會影響全局。

12. 降級和限流

? ? ?關于降級限流的方法業界都已經有很成熟的方法了，比如FAILBACK機制，限流的方法令牌桶，漏桶，信號量等。這里談一下我們的一些經驗，降級一般都是由統一配置中心的降級開關來實現的，那么當有很多個接口來自同一個提供方，這個提供方的系統或這機器所在機房網絡出現了問題，我們就要有一個統一的降級開關，不然就要一個接口一個接口的來降級。也就是要對業務類型有一個大閘刀。還有就是 降級切記暴力降級，什么是暴力降級的，比如把論壇功能降調，結果用戶顯示一個大白板，我們要實現緩存住一些數據，也就是有托底數據。限流一般分為分布式限流和單機限流，如果實現分布式限流的話就要一個公共的后端存儲服務比如redis，在大nginx節點上利用lua讀取redis配置信息。我們現在的限流都是單機限流，并沒有實施分布式限流。

13. 網關監控和統計

? ? ?API網關是一個串行的調用，那么每一步發生的異常要記錄下來，統一存儲到一個地方比如elasticserach中，便于后續對調用異常的分析。鑒于公司docker申請都是統一分配，而且分配之前docker上已經存在3個agent了，不再允許增加。我們自己實現了一個agent程序，來負責采集服務器上面的日志輸出，然后發送到kafka集群，再消費到elasticserach中，通過web查詢。現在做的追蹤功能還比較簡單，這塊還需要繼續豐富。

四、微服務總結：

1、單獨地說，微服務在內部類似于單片應用程序。

2、指導微服務架構的原則反映了組織目標，并告知了團隊實踐。

3、你的架構計劃應該鼓勵良好的發展，而不是為你的整體應用規定方法。

4、平臺層提供工具、管道和基礎設施來支持面向產品的微服務的開發。

5、同步通信通常是微服務應用程序的首選，最適合于命令類型的交互，但它也有缺點，會增加耦合性和脆弱性。

6、異步通信更加靈活，能夠適應快速的系統演化，但代價是增加了復雜性。

7、常見的異步通信模式包括隊列和發布-訂閱。

8、邊界層為微服務應用程序提供了一個適合外部使用者的外觀。

9、常見的邊界類型包括API網關和用戶驅動的網關，例如GraphQL。

10、客戶端應用程序，如網站和移動應用程序，通過邊界層與您的移動后端交互。

11、客戶端可能會變得孤立，但將微服務原則應用于前端應用的技術已經開始出現。

?

?

總結

以上是生活随笔為你收集整理的软件服务工程课程总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。