名詞記憶

CAP理論，CAP原則又稱CAP定理，指的是在一個分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。

Consistency(一致性), 數據一致更新，全部數據變更都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容錯性) 可靠性

定理：任何分佈式系統只可同時知足二點，無法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能知足三者的完美分佈式系統，而是應該進行取捨。

關係數據庫的ACID模型擁有 高一致性 + 可用性 很難進行分區：
Atomicity原子性：一個事務中全部操做都必須所有完成，要麼所有不完成。
Consistency一致性. 在事務開始或結束時，數據庫應該在一致狀態。
Isolation隔離層. 事務將假定只有它本身在操做數據庫，彼此不知曉。
Durability. 一旦事務完成，就不能返回。
跨數據庫事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務能夠支持2PC。由於2PC是反模式，儘可能不要使用2PC，使用BASE來回避。

BASE模型反ACID模型，徹底不一樣ACID模型，犧牲高一致性，得到可用性或可靠性：
Basically Available基本可用。支持分區失敗(e.g. sharding碎片劃分數據庫)
Soft state軟狀態 狀態能夠有一段時間不一樣步，異步。
Eventually consistent最終一致，最終數據是一致的就能夠了，而不是時時高一致。

BASE思想的主要實現有
1.按功能劃分數據庫
2.sharding碎片 

BASE思想主要強調基本的可用性，若是你須要High 可用性，也就是純粹的高性能，那麼就要以一致性或容錯性爲犧牲，BASE思想的方案在性能上仍是有潛力可挖的。

如今NOSQL運動豐富了拓展了BASE思想，可按照具體狀況定製特別方案，好比忽視一致性，得到高可用性等等，NOSQL應該有下面兩個流派：1. Key-Value存儲，如Amaze Dynamo等，可根據CAP三原則靈活選擇不一樣傾向的數據庫產品。2. 領域模型 + 分佈式緩存 + 存儲 （Qi4j和NoSql運動），可根據CAP三原則結合本身項目定製靈活的分佈式方案，難度高。
這二者共同點：都是關係數據庫SQL之外的可選方案，邏輯隨着數據分佈，任何模型均可以本身持久化，將數據處理和數據存儲分離，將讀和寫分離，存儲能夠是異步或同步，取決於對一致性的要求程度。不一樣點：NOSQL之類的Key-Value存儲產品是和關係數據庫頭碰頭的產品BOX，能夠適合非Java如PHP RUBY等領域，是一種能夠拿來就用的產品，而領域模型 + 分佈式緩存 + 存儲是一種複雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。

 

一、RMI

    使用java的程序員，對於RMI（RemoteMethod Invoke，遠程方法調用）必定不陌生，在java中，爲了在分佈式應用開發時，可以方便調用遠程對象，java提供了RMI的API。在 RMI 中,遠程對象按照好象它是本地行事，客戶機應用程序會直接調用遠程對象存根上的方法，所以，調用起來就如本地對象同樣方便。RMI中封裝了對象和請求的網 絡傳送，使得異地的對象服務直接可用。

但RMI的使用必須是在可以識別java代碼的環境下使用，即必須有JVM的支持。所以，他只適合在java程序間的對象通訊。若是不在 Java 環境下工做,或者須要與非 Java 環境通訊，那麼SOAP、RPC、CORAR等都是能夠的。.

二、RPC & XML-RPC

       RPC（Remote Method Invocation，遠端過程調用） 與RMI的區別很明顯，相比於RMI直接獲取遠端方法的簽名，進行調用的方式，RPC使用的是C/S方式，發送請求到服務器，等待服務器返回結果。

爲了包裝RPC的請求信息，推出了XML-RPC，客戶端發送一條特定消息，該消息中必須包括名稱、運行服務的程序以及輸入參數。

XML-RPC只能使用有限的數據類型種類和一些簡單的數據結構。SOAP最主要的工做是使用標準的XML描述了RPC的請求信息(URI/類/方法/參數/返回值)。SOAP的方式，SOAP 是對如CORBA 和 RMI-IIOP 這樣的重型 範例吸引人的替代。

三、SOAP

       SOAP的消息被稱爲一個SOAP Envelope，包括SOAP Header和SOAP Body。其中，SOAP Header能夠方便的插入各類其它消息來擴充Web Service的功能，好比Security（採用證書訪問Web Service），SOAP Body則是具體的消息正文，也就是Marshall後的信息。

       某些程序員天天掙扎於 Perl 和 C 組件、C 和 Java 組件之間的通訊。這些開發人員能夠從轉向基於 SOAP 或基於 XML-RPC 的通訊模型中獲益匪淺。另外一方面，從不轉向 Java 之外語言的 Java 開發人員能夠轉向 RMI 而不是使用 SOAP，他們會看到極大的性能改善。

四、WSDL

WSDL(Web Services Description Language)是描述web服務的，是描述怎樣訪問web服務的。WSDL是用來描述SOAP的，換句話說，WSDL 文件告訴你調用 SOAP 所須要知道的一切。WSDL也是一段xml。如今各個語言對wsdl的支持都很成熟，能夠根據同一份wsdl文件生成本身語言的客戶端。

五、REST

須要注意的是，REST是設計風格而不是標準。REST一般基於使用HTTP，URI，和XML（標準通用標記語言下的一個子集）以及HTML（標準通用標記語言下的一個應用）這些現有的普遍流行的協議和標準。REST即表述性狀態傳遞（英文：Representational State Transfer，簡稱REST）

 

 

RUP（Rational Unified Process）， 統一軟件開發過程， 統一軟件過程)是一個 面向對象且基於網絡的程序開發方法論。

瑞理統一過程（RUP）是Rational軟件公司（Rational公司被IBM併購）創造的軟件工程方法[1]   。RUP描述瞭如何有效地利用商業的可靠的方法開發和部署軟件，是一種重量級過程（也被稱做厚方法學），所以特別適用於大型軟件團隊開發大型項目。

 

RUP最重要的它有三大特色：1）軟件開發是一個迭代過程，2）軟件開發是由Use Case驅動的，3）軟件開發是以架構設計（Architectural Design）爲中心的。

 

CMMI全稱是Capability Maturity Model Integration，即能力成熟度模型集成（也有稱爲：軟件能力成熟度集成模型）[1]   ，是 美國國防部的一個設想，1994年由美國國防部（United States Department of Defense）與卡內基-梅隆大學（Carnegie-Mellon University）下的軟件工程研究中心（Software Engineering Institute，SEISM）以及美國國防工業協會（National Defense Industrial Association）共同開發和研製的，他們計劃把如今全部現存實施的與即將被髮展出來的各類能力成熟度模型，集成到一個框架中去，申請此認證的前提條件是該企業具備有效的軟件企業認定證書。

其目的是幫助軟件企業對 軟件工程過程進行管理和改進，加強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟件。其所依據的想法是：只要集中精力持續努力去創建有效的軟件工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就能夠克服軟件開發中的困難。CMMI爲改進一個組織的各類過程提供了一個單一的集成化框架，新的集成模型框架消除了各個模型的不一致性，減小了模型間的重複，增長透明度和理解，創建了一個自動的、可擴展的框架。於是可以從整體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。

 

實施流程

階段1：CMMI項目啓動會

明確企業實施CMMI的商業目標，創建CMMI項目實施的溝通機制。

階段2：CMMI基礎培訓和過程改進小組（EPG）組建

進行CMMI基礎概念講解，指導企業創建核心的過程改進小組。

階段3：診斷

充分了解企業研發過程現狀，識別企業現有軟件過程與企業現階段理應達到的CMMI成熟度級別的差距，提交診斷報告，進行過程改進的策劃。

階段4：過程域培訓和文件定義

結合企業過程現狀進行CMMI過程域培訓，經過舉例、案例分析等方式，讓企業的EPG掌握過程文件定義技巧，結合企業實際狀況有針對性的定義組織的研發過程，並肯定過程產出物（如：需求報告）

階段5：項目試點

選擇表明公司核心業務的項目或者典型項目進行試點，經過試點來完善過程文件，從而爲企業全面推廣過程文件打下基礎。

階段6：組織推廣

全員參與全面導入與執行CMMI。

階段7：預評估

驗證組織推廣的結果，識別企業尚存缺陷並制定再次改善方案，準備充分，以便企業可以更好進行正式SCAMPI評估。

階段8：SCAMPI A 正式評估

由SEI受權的主任評估師領導，採用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)評估方法，對企業的能力成熟度進行正式的評估，頒發證書，經過SEI網站向全球發佈企業信息。

CMMI主要內容及各過程域的相互關係

CMMI 二、3級共有18個過程域（PA）,主要內容以下，分四大類：
　　1、過程管理：
　　1． OPD：組織級過程定義。
　　2． OPF：組織級過程焦點。
　　3． OT：組織培訓管理。
　　2、項目管理：
　　4． PP：項目計劃。
　　5． PMC：項目監督與控制。
　　6． SAM：供應商協議管理。
　　7． IPM：集成項目管理。
　　8． RSKM：風險管理。

3、工程管理:

9． REQM：需求管理。

10． RD：需求開發。

11． TS：技術解決方案。
　　12． PI：產品集成。
　　13． VER：驗證。
　　14． VAL：確認。
　　4、支持管理：
　　15． CM：配置管理。
　　16． PPQA：過程和產品質量保證。
　　17． MA：測量與分析。
　　18． DAR：決策分析與解決。
　　CMMI 4級除第二、3級所涵蓋的18個過程域外，增長如下兩個過程域：
　　19. OPP ：組織過程性能。
　　20. QPM：量化的項目管理 。

CMMI 5級包含第2級到第4級的20個過程域外，

增長如下兩個過程域：
　　21. OID：組織創新與推展。
　　22. CAR：因果分析與解決方案。

CMMI模型表述階段式：
　　一、階段式表述提供系統化與結構化的方式，一次一個階段達到以模型爲基礎的過程改進。達成每個階段可確保有足夠的過程基礎建設，可做爲下一個階段過程改進的基礎。

　　二、連續式：連續式表述可提供最大的彈性。一個組織能夠選擇改進單一過程相關的問題點的績效，或是可使用多個領域以密切配合組織的經營目標。

 

極限編程（ExtremeProgramming，簡稱XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期與WardCunningham共事時，就一直共同探索着新的軟件開發方法，但願能使軟件開發更加簡單而有效。Kent仔細地觀察和分析了各類簡化軟件開發的前提條件、可能性以及面臨的困難。1996年三月，Kent終於在爲DaimlerChrysler所作的一個項目中引入了新的軟件開發觀念——XP。適用於小團隊開發。

 極限編程中有四個核心價值是咱們在開發中必須注意的：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、此外還擴展了第五個價值觀：謙遜（Modesty）。 

 

方法

基於敏捷的核心思想和價值目標，XP要求項目團隊遵循13個核心實踐

團隊協做(Whole Team)

規劃策略(The Planning Game)；

結對編程(Pair programming)

測試驅動開發(Testing-Driven Development)

重構(Refactoring)

簡單設計(Simple Design)

代碼集體全部權(Collective Code Ownership)

持續集成(Continuous Integration)

客戶測試(Customer Tests)

小型發佈（Small Release）

每週40小時工做制（40-hour Week）

編碼規範（Code Standards）

系統隱喻（System Metaphor）

 

極限編程的4個商業實踐：

• 測試驅動開發—TDD是你的商業安全網。由於測試是在編碼以前完成的，因此寫完的測試必定會運行失敗，接下來再寫代碼使測試能夠經過。TDD保證你的產品功能，無論公司和技術團隊實現的是大規模的變動仍是小規模的變動。
• 結對編程—讓2名開發人員寫同一段代碼，使用同一個鍵盤和同一臺顯示器。由於結對大大下降了浪費的時間和缺陷，因此能帶來更高質量的代碼，並帶來高水平的協做。
• 集體代碼全部制和持續集成—若是每段代碼不僅有一我的熟悉，那麼就不會有什麼交流瓶頸了。把代碼持續集成到一個主幹能夠避免重複和不匹配的代碼。
• 重構—在當時的狀況下，寫的代碼是解決已知問題的。一般，團隊巧妙地解決了他們的問題，而後持續重構和修改代碼，確保代碼庫能以最爲高效的方式不斷知足業務最新的須要

•  

 

 

 

RUP是一套管理方法，用於項目從需求到發佈的管理而敏捷則是一種思想，一種價值觀：價值迭代交付，以人爲本有一些基於敏捷思想的實踐好比Scrum、XP等也都是管理方法或開發方法層面的內容RUP能夠與敏捷的思想結合，能夠在敏捷思想指導下進行管理，那就是敏捷的RUP

XP 與CMM 、RUP 的比較
CMM 告訴組織爲了系統化地創建、實施和改進軟件開發過程應該作些什麼，但沒有說明如何去作以及採用哪些具體的技術、策略和方法。CMM 是一套通用的過程實踐標準，適用面很廣。實施CMM 要求組織在過程的制度化建設上付出大量努力，一般被認爲是重載（heavy-weight）的模型。
XP 是一個針對某種特定環境（需求變化快的小型團隊）的具體過程實施模型和方法論。它實際上是一種演進式的原型化方法（evolutionary prototyping）[MCNL96]，具備溝通高效、設計簡單、反饋迅速等特色，於是是一種輕載（light-weight）、敏捷（agile） 的過程方法。
Mark Paulk 在他的文章中把XP 的實踐方法與CMM 的KPA（關鍵過程域）進行了對照。得出的結論是，XP部分知足或大部分知足了CMM 2-3 級KPA 的要求，而基本上沒有涉及CMM 4-5 級的KPA。這說明XP 的作法基本符合了CMM 的目標和KPA，但還不完備。整體上看，XP 側重於具體的過程和開發技術，而CMM 更關注組織和管理上的問題。XP 缺乏的一個重要內容是「制度化（institutionalization）」，它不含有被CMM 認爲是使良好的工程和管理實踐制度化的關鍵基礎設施和管理要件。[PALK01]
RUP（Rational Unified Process）是一個風險驅動的基於UML 和構件式架構的迭代遞增型開發過程（框架）。RUP 定義了4 個階段（起始、細化、構造、移交）和9 個科目（業務建模、需求、分析和設計、實現、測試、部署、配置和變動管理、項目管理、環境）。這些階段對應着關鍵里程碑的劃分，而不一樣科目的工做流和活動 在生命週期的迭代中能夠併發進行，具體執行的程度則能夠調節。RUP 對於角色、流程、工件和活動的要求是靈活的、可配置的，因此它普遍地適用於各類類型和規模的項目。RUP 集中體現了6 個軟件開發的最佳實踐方法：迭代式開發、需求管理、構件式架構、基於UML 的可視化建模、持續校驗質量、變動管理。RUP 是一種以架構爲中心的開發過程，而這正是大、中型項目成功的關鍵。
XP 的編碼和設計活動融爲一體，弱化了架構的概念，這是它與強調架構設計的RUP 的最大不一樣。架構的內涵要遠大於一些簡單的隱喻，它要考慮結構、行爲、環境、使用、功能、性能、可靠性、彈性、重用、可理解性、約束和權衡乃至美學等諸多 方面的因素。設計架構的目的不是爲了完美地表示系統的所有細節，而是爲了消除最主要和最關鍵的架構風險。RUP 細化階段的主要目的就是構造出一個可運行的架構原型，做爲未來添加需求功能的穩固基礎。另外，XP 沒有包含業務建模、部署等概念，反映了它以編程爲中心、節省一切的哲學。
固然二者也有很多共同點。例如，它們的基礎都是面向對象方法（取代傳統的結構化方法），都重視代碼、文檔的最小化和設計的簡化，採用動態適應變化的演進式迭代週期（取代傳統的瀑布型生命週期）、需求和測試驅動並鼓勵用戶積極參與等等。
由 於RUP 提供了很是豐富的內容，因此經常被誤解爲一個重載的過程。經過定製RUP 這個通用的過程框架，去掉項目沒必要要的工件（artifacts）和中間環節，把XP 的作法（好比短小的迭代週期、結對編程、測試優先的設計和重構）吸取進來，也能夠實現RUP 過程的敏捷和輕量化[SMTH01]。「Bob 大叔」（Robert Martin）甚至從RUP中裁剪出了一個酷似XP 的最小化RUP 過程——dx[MART01]。我設想，XP、RUP 乃至其餘工程和管理方法能夠統一塊兒來使用，姑且成之爲統一軟件過程（Unified Software Process，USP）。例如，一個大項目團隊在起始和細化階段採用RUP 方法完成需求分析和架構設計，在構造和移交階段採用XP 的作法來實現部分子系統或模塊。
「輕載」、「敏捷」是美麗的詞彙，無人會拒之於門外。我想XP、RUP 的目標是一致的——提升團隊效率、開發出高質量的軟件，而區別就在於各自的側重點不一樣，從而致使二者的適用狀況和應用範圍有差別。然而，它們是能夠互補 的，不管是以架構爲中心，仍是以代碼爲中心，靈活運用的關鍵就在於掌握其中的最佳實踐方法，實施RUP、XP 或者融合了二者的過程（好比USP）都將有助於組織更好地實現CMM 目標。

 

項目	CMM/CMMI	RUP	MSF	XP
週期	螺旋模型。	演進式迭代週期，過程框架	瀑布模型和螺旋模型的結合	演進式迭代週期。軟件開發方法學
核心	過程改進	架構、迭代	里程碑、迭代	以代碼爲中心。
範圍	需求嚴格而極少變化的項目。	適合不一樣類型的項目	適合不一樣類型的項目	進度緊、需求不穩定的小項目、小型發佈和小團隊
組織	我的（PSP）、團隊（TSP）和組織的3個層次，組間協做、培訓	跨團隊協做	強調產品的願景，6種基本角色	以團隊爲基礎，小團隊、團隊成員能力至關
技術	傳統結構化方法	面向對象技術	綜合技術	面向對象技術
管理	側重於過程的定義、度量和改進。一切用數字和文檔說話。	從組織角度出發，側重於過程建模、部署。	業務建模、部署、過程管理等概念。	側重於具體的過程執行和開發技術，計劃設計。
活動	經過過程域來定義活動	整個團隊在整個過程當中關注質量	項目管理、風險管理和就緒管理	以人爲本，如每週40小時工做制、結對編程
實踐	各種級別的關鍵實踐。 重視關鍵基礎設施。	知足了CMM 2-3 級KPA 的要求，而基本上沒有涉及CMM 4-5 級的KPA	代碼複審、版本管理方法、文檔管理、人員招聘、重測試和重風險管理等。	編碼和設計活動融爲一體，弱化了架構。 用例、單元測試、迭代開發和分層的架構。
其它	通用性強，但複雜、高成本。	強調風險驅動，以保障可用產品的持續性交付爲前提，儘可能減小沒必要要的過程工件，使度量、文檔最小化以得到彈性和應變能力。	提供了一系列指南，用於規劃企業的基礎技術設施，流程化商業的運做過程，並鼓勵重用性。	擁抱變化，強調人性化、簡單、溝通。儘可能減小文檔。 個體和交互賽過過程和工具。