第一周

云計算

什么是云計算

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

Saas軟件即服務(wù)面臨的挑戰(zhàn)和它的適用性

挑戰(zhàn)一：轉(zhuǎn)換成本高。解決方案是提升服務(wù)質(zhì)量，增強客戶滿意度。

挑戰(zhàn)二：有限的靈活性。解決方案是提供應(yīng)用程序交換平臺，提供可定制化服務(wù)。

挑戰(zhàn)三：安全性和隱私性。解決方案是盡可能謹(jǐn)慎并更加專業(yè)化。

SaaS的適用性：

1、企業(yè)軟件應(yīng)用

• 執(zhí)行業(yè)務(wù)功能
• 組織內(nèi)部和外部信息
• 在內(nèi)部和外部用戶之間共享數(shù)據(jù)
• 適用于Saas模型的最標(biāo)準(zhǔn)類型的軟件
• 示例：Saleforce.com CRM應(yīng)用?Siebel On-demand 程序

2、單用戶軟件應(yīng)用

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

3、基礎(chǔ)設(shè)施軟件

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

4、嵌入式軟件

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

?

PaaS的概念

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

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

IaaS的概念

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

AMI（Amazon Machine Images）

AMI是一種使用亞馬遜云計算服務(wù)時創(chuàng)建的機器鏡像，機器鏡像中包括操作系統(tǒng)、應(yīng)用程序和配置設(shè)置。

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

Hadoop

Hadoop是一個由apache基金會所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu)，用戶可以在不了解分布式底層細(xì)節(jié)的情況下，開發(fā)分布式程序，Hadoop的使用和流行使人們可以充分利用集群的能力進行高速運算和存儲。

Hadoop各組件：

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

DevOps介紹

DevOps 是一個完整的面向IT運維的工作流，以 IT 自動化以及持續(xù)集成（CI）、持續(xù)部署（CD）為基礎(chǔ)，來優(yōu)化程式開發(fā)、測試、系統(tǒng)運維等所有環(huán)節(jié)。

SOA面向服務(wù)架構(gòu)相關(guān)概念，微服務(wù)概念

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

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

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

• 一組小的服務(wù)?

• 獨立部署運行和擴展?

• 獨立開發(fā)和演化?

• 獨立團隊和自治?

第二周

敏捷

敏捷是一組用于軟件產(chǎn)品開發(fā)的實踐、價值和原則。

敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法。它不是一門技術(shù)，它是一種開發(fā)方法，也就是一種軟件開發(fā)的流程，它會指導(dǎo)我們用規(guī)定的環(huán)節(jié)去一步一步完成項目的開發(fā)；而這種開發(fā)方式的主要驅(qū)動核心是人；它采用的是迭代式開發(fā)。

?

為什么要用敏捷開發(fā)：敏捷使軟件產(chǎn)品更好地響應(yīng)客戶需求，同時可以有效節(jié)省精力和資金。

傳統(tǒng)的開發(fā)模型可能會增加客戶的成本，原因如下：

1、新技術(shù)不斷引進。

2、新玩家進入市場，

3、增加了新的要求

4、“小即美”

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

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

?

敏捷開發(fā)和傳統(tǒng)開發(fā)對比：

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

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

?

敏捷開發(fā)的原則：

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

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

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

4、同一個項目的業(yè)務(wù)人員和開發(fā)人員必須在一起工作。

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

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

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

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

9、持續(xù)關(guān)注技術(shù)的卓越性和良好的設(shè)計可以提高敏捷性。

10、簡潔是必不可少的。

11、組建團隊實現(xiàn)最好的架構(gòu)、需求和設(shè)計。

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

?

敏捷方法：scrum

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

產(chǎn)品負(fù)責(zé)人（Product Owner）

主要負(fù)責(zé)確定產(chǎn)品的功能和達(dá)到要求的標(biāo)準(zhǔn)，指定軟件的發(fā)布日期和交付的內(nèi)容，同時有權(quán)力接受或拒絕開發(fā)團隊的工作成果。

流程管理員（Scrum Master）

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

開發(fā)團隊（Scrum Team）

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

如何進行scrum開發(fā)：

1、我們首先需要確定一個Product Backlog（按優(yōu)先順序排列的一個產(chǎn)品需求列表），這個是由Product Owner 負(fù)責(zé)的；

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

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

4、Sprint Backlog是由Scrum Team去完成的，每個成員根據(jù)Sprint Backlog再細(xì)化成更小的任務(wù)（細(xì)到每個任務(wù)的工作量在2天內(nèi)能完成）；

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

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

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

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

敏捷估算

計劃撲克玩法

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

第三周

scrum

scrum中的迭代方式

1、迭代計劃——為一次迭代創(chuàng)建一個計劃

選擇下一個要交付的內(nèi)容（按優(yōu)先級選擇），定義和估計任務(wù)，協(xié)商交付產(chǎn)品的范圍

2、迭代執(zhí)行——實現(xiàn)計劃中的項目

處理需求、設(shè)計、代碼、集成/構(gòu)建，并測試計劃中需要的模塊

3、交付迭代的結(jié)果——給出demo

步驟1-3將根據(jù)發(fā)布計劃多次執(zhí)行

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

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

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

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

scrum角色

scrum小組

scrum板

待辦事項

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

• Detailed 合適的詳細(xì)程度，高優(yōu)先級需求更加明細(xì)，低優(yōu)先級的需求粒度更大
• Emergent 涌現(xiàn)式的，需求是慢慢涌現(xiàn)出來的，漸進明細(xì)的
• Estimated 經(jīng)過估算的
• Prioritized/ Ordered 根據(jù)商業(yè)價值排好順序的

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

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

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

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

scrum管理工具

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

第四周

軟件系統(tǒng)架構(gòu)演變

1.1 單一應(yīng)用架構(gòu)

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

1.2 垂直應(yīng)用架構(gòu)

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

1.3 分布式服務(wù)架構(gòu)

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

1.4 流動計算架構(gòu)

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

?

一、微服務(wù)介紹

1. 什么是微服務(wù)

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

2. 微服務(wù)由來

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

3. 為什么需要微服務(wù)？

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

3.1 最期的單體架構(gòu)帶來的問題

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

1.復(fù)雜性逐漸變高

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

2.技術(shù)債務(wù)逐漸上升

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

3.部署速度逐漸變慢

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

4.阻礙技術(shù)創(chuàng)新

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

5.無法按需伸縮

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

3.2 微服務(wù)與單體架構(gòu)區(qū)別

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

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

3、單體架構(gòu)所有的模塊開發(fā)所使用的技術(shù)一樣，微服務(wù)每個模塊都可以使用不同的開發(fā)技術(shù)，開發(fā)模式更靈活。

3.3 微服務(wù)與SOA區(qū)別

微服務(wù)，從本質(zhì)意義上看，還是 SOA 架構(gòu)。但內(nèi)涵有所不同，微服務(wù)并不綁定某種特殊的技術(shù)，在一個微服務(wù)的系統(tǒng)中，可以有 Java 編寫的服務(wù)，也可以有 Python編寫的服務(wù)，他們是靠Restful架構(gòu)風(fēng)格統(tǒng)一成一個系統(tǒng)的。所以微服務(wù)本身與具體技術(shù)實現(xiàn)無關(guān)，擴展性強。

4. 微服務(wù)本質(zhì)

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

2、微服務(wù)的目的是有效的拆分應(yīng)用，實現(xiàn)敏捷開發(fā)和部署 。

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

5. 什么樣的項目適合微服務(wù)

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

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

小：微服務(wù)體積小，2 pizza 團隊。

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

輕：使用輕量級的通信機制和架構(gòu)。

松：為服務(wù)之間是松耦合的。

微服務(wù)折分與設(shè)計

1、從單體式結(jié)構(gòu)轉(zhuǎn)向微服務(wù)架構(gòu)中會持續(xù)碰到服務(wù)邊界劃分的問題：比如，我們有user 服務(wù)來提供用戶的基礎(chǔ)信息，那么用戶的頭像和圖片等是應(yīng)該單獨劃分為一個新的service更好還是應(yīng)該合并到user服務(wù)里呢？如果服務(wù)的粒度劃分的過粗，那就回到了單體式的老路；如果過細(xì)，那服務(wù)間調(diào)用的開銷就變得不可忽視了，管理難度也會指數(shù)級增加。目前為止還沒有一個可以稱之為服務(wù)邊界劃分的標(biāo)準(zhǔn)，只能根據(jù)不同的業(yè)務(wù)系統(tǒng)加以調(diào)節(jié)

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

6.1 微服務(wù)設(shè)計原則

單一職責(zé)原則

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

服務(wù)自治原則

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

輕量級通信原則

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

接口明確原則

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

7. 微服務(wù)優(yōu)勢與缺點

7.1 特性

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

2、一系列獨立運行的微服務(wù)共同構(gòu)建起了整個系統(tǒng)；

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

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

7.2 特點

易于開發(fā)和維護

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

啟動較快

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

局部修改容易部署

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

技術(shù)棧不受限

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

按需伸縮

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

7.3 缺點

運維要求較高

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

分布式的復(fù)雜性

對于單體架構(gòu)來講，我們可以不使用分布式，但是對于微服務(wù)架構(gòu)來說，分布式幾乎是必會用的技術(shù)，由于分布式本身的復(fù)雜性，導(dǎo)致微服務(wù)架構(gòu)也變得復(fù)雜起來。

接口調(diào)整成本高

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

重復(fù)勞動

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

8. 微服務(wù)開發(fā)框架

目前微服務(wù)的開發(fā)框架，最常用的有以下四個：

Spring Cloud：http://projects.spring.io/spring-cloud（現(xiàn)在非常流行的微服務(wù)架構(gòu)）

Dubbo：http：//dubbo.io

Dropwizard：http://www.dropwizard.io （關(guān)注單個微服務(wù)的開發(fā)）

Consul、etcd&etc.（微服務(wù)的模塊）

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

?

9. Sprint cloud 和 Sprint boot區(qū)別

Spring Boot:

旨在簡化創(chuàng)建產(chǎn)品級的Spring應(yīng)用和服務(wù)，簡化了配置文件，使用嵌入式web服務(wù)器，含有諸多開箱即用微服務(wù)功能，可以和spring cloud聯(lián)合部署。

?Spring Cloud：

微服務(wù)工具包，為開發(fā)者提供了在分布式系統(tǒng)的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線等開發(fā)工具包。

二、微服務(wù)實踐先知

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

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

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

提供統(tǒng)一服務(wù)入口，讓微服務(wù)對前臺透明

聚合后臺的服務(wù)，節(jié)省流量，提升性能

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

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

2. 服務(wù)之間如何通信？（服務(wù)調(diào)用）

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

REST（JAX-RS，Spring Boot）

RPC（Thrift, Dubbo）

異步消息調(diào)用(Kafka, Notify)

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

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

3. 這么多服務(wù)怎么查找？（服務(wù)發(fā)現(xiàn)）

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

客戶端做：優(yōu)點是架構(gòu)簡單，擴展靈活，只對服務(wù)注冊器依賴。缺點是客戶端要維護所有調(diào)用服務(wù)的地址，有技術(shù)難度，一般大公司都有成熟的內(nèi)部框架支持，比如Dubbo。?

服務(wù)端做：優(yōu)點是簡單，所有服務(wù)對于前臺調(diào)用方透明，一般在小公司在云服務(wù)上部署的應(yīng)用采用的比較多。

4. 服務(wù)掛了怎么辦？

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

重試機制

限流

熔斷機制

負(fù)載均衡

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

5. 微服務(wù)需要考慮的問題

API Gateway?? 服務(wù)間調(diào)用? 服務(wù)發(fā)現(xiàn)? 服務(wù)容錯? 服務(wù)部署?? 數(shù)據(jù)調(diào)用

6、微服務(wù)的開發(fā)生命周期

設(shè)計? ?開發(fā)? ?觀察? ?依次循環(huán)

三、微服務(wù)重要部件

1. 微服務(wù)基本能力

2. 服務(wù)注冊中心

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

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

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

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

zookeeper —— 在分布式應(yīng)用中被廣泛使用，高性能的協(xié)調(diào)服務(wù)。 Apache Zookeeper 最初為Hadoop的一個子項目，但現(xiàn)在是一個頂級項目。

2.1 zookeeper服務(wù)注冊和發(fā)現(xiàn)

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

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

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

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

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

3. 負(fù)載均衡

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

3.1 負(fù)載均衡的常見策略

3.1.1 隨機

把來自網(wǎng)絡(luò)的請求隨機分配給內(nèi)部中的多個服務(wù)器。

3.1.2 輪詢

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

3.1.3 加權(quán)輪詢

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

3.1.4 IP Hash

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

3.1.5 最少連接數(shù)

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

4. 容錯

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

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

4.1 容錯策略

4.1.1 快速失敗

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

4.1.2 失效切換

服務(wù)發(fā)起調(diào)用，當(dāng)出現(xiàn)失敗后，重試其他服務(wù)器。通常用于讀操作，但重試會帶來更長時間的延遲。重試的次數(shù)通常是可以設(shè)置的

4.1.3 失敗安全

失敗安全， 當(dāng)服務(wù)調(diào)用出現(xiàn)異常時，直接忽略。通常用于寫入日志等操作。

4.1.4 失敗自動恢復(fù)

當(dāng)服務(wù)調(diào)用出現(xiàn)異常時，記錄失敗請求，定時重發(fā)。通常用于消息通知。

4.1.5 forking Cluster

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

4.1.6 廣播調(diào)用

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

5. 熔斷

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

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

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

我們可以用狀態(tài)機來實現(xiàn)CircuitBreaker，它有以下三種狀態(tài)：

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

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

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

6. 限流和降級

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

7. SLA

SLA：Service-LevelAgreement的縮寫，意思是服務(wù)等級協(xié)議。 是關(guān)于網(wǎng)絡(luò)服務(wù)供應(yīng)商和客戶間的一份合同，其中定義了服務(wù)類型、服務(wù)質(zhì)量和客戶付款等術(shù)語。 典型的SLA包括以下項目：

分配給客戶的最小帶寬；

客戶帶寬極限；

能同時服務(wù)的客戶數(shù)目；

在可能影響用戶行為的網(wǎng)絡(luò)變化之前的通知安排；

撥入訪問可用性；

運用統(tǒng)計學(xué)；

服務(wù)供應(yīng)商支持的最小網(wǎng)絡(luò)利用性能，如99.9%有效工作時間或每天最多為1分鐘的停機時間；

各類客戶的流量優(yōu)先權(quán)；

客戶技術(shù)支持和服務(wù)；

懲罰規(guī)定，為服務(wù)供應(yīng)商不能滿足 SLA需求所指定。

8. API網(wǎng)關(guān)

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

9. 多級緩存

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

10. 超時和重試

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

11. 線程池隔離

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

12. 降級和限流

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

13. 網(wǎng)關(guān)監(jiān)控和統(tǒng)計

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

四、微服務(wù)總結(jié)：

1、單獨地說，微服務(wù)在內(nèi)部類似于單片應(yīng)用程序。

2、指導(dǎo)微服務(wù)架構(gòu)的原則反映了組織目標(biāo)，并告知了團隊實踐。

3、你的架構(gòu)計劃應(yīng)該鼓勵良好的發(fā)展，而不是為你的整體應(yīng)用規(guī)定方法。

4、平臺層提供工具、管道和基礎(chǔ)設(shè)施來支持面向產(chǎn)品的微服務(wù)的開發(fā)。

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

6、異步通信更加靈活，能夠適應(yīng)快速的系統(tǒng)演化，但代價是增加了復(fù)雜性。

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

8、邊界層為微服務(wù)應(yīng)用程序提供了一個適合外部使用者的外觀。

9、常見的邊界類型包括API網(wǎng)關(guān)和用戶驅(qū)動的網(wǎng)關(guān)，例如GraphQL。

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

11、客戶端可能會變得孤立，但將微服務(wù)原則應(yīng)用于前端應(yīng)用的技術(shù)已經(jīng)開始出現(xiàn)。

?

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。