讓咱們一塊兒 回憶：html
| 原則 |
基本認識 |
| S |
應該僅有一個引發它變化的緣由 |
| O |
在不被修改的前提下被擴展 |
| L |
儘可能從抽象類繼承 |
| I |
應該依賴於抽象 |
| D |
傾向瘦接口 |
讓咱們開始 新課：前端
[Design Patterns] 03. Practice UML in project 的 "文檔列表" 其實就是」過程模式「的一種。android
「設計模式」會在未來單獨講解git
這裏主要學習「體系結構模式」和「分析模式」。github
體系架構模式
Ref: 10種常見的軟件架構模式數據庫
Ref: 軟件架構模式 (30頁的書)編程
若干重要模式
黑板模式
這種模式對於沒有肯定解決方案策略的問題是有用的。黑板模式由3個主要組成部分組成。後端
-
- 黑板——包含來自解決方案空間的對象的結構化全局內存
- 知識源——專門的模塊和它們本身的表示
- 控制組件——選擇、配置和執行模塊
全部的組件均可以訪問黑板。設計模式
組件能夠生成添加到黑板上的新數據對象。瀏覽器
組件在黑板上查找特定類型的數據，並經過與現有知識源的模式匹配來查找這些數據。
使用場景：
-
- 語音識別
- 車輛識別和跟蹤
- 蛋白質結構識別
- 聲納信號的解釋
利用數據庫
高頻率的訪問數據庫，不利於實時
利用發佈—訂閱模式
【這其實就是聊天功能】
這種實現方式一般
採用消息隊列做爲黑板，隊列工做在主題模式（Topic），專家做爲隊列的訂閱者，同時能夠向隊列發送消息，消息會被髮送至全部訂閱者。以上過程實現了專家間的信息交流。
特色：
1 能夠有效應用於實時性要求較高的系統，這種實現工做在「推模式」下。
2 難於實現信息的統計分析，不像實現方式一那樣能夠經過SQL支持，這些工做必須開發者本身完成。
MVC模式（模型-視圖-控制器）
Ref: Android Module] 03 - Software Design and Architecture
一個小的項目且無需頻繁修改需求就不用MVC框架來設計了，那樣反而以爲代碼過分設計，代碼臃腫。
通常在大的項目中，且業務邏輯處理複雜，頁面顯示比較多，須要模塊化設計的項目使用MVC就有足夠的優點了。
【是否是還有更大的項目，那該如何?】
在MVC模式中咱們發現，其實控制器Activity主要是起到解耦做用，將View視圖和Model模型分離。
-
- View 視圖和Activity 控制器並非徹底分離的
- 雖然Activity起到交互做用，可是找Activity中有不少關於視圖UI的顯示代碼
【須要清除掉activity中的視圖代碼殘渣，但仍是先把業務邏輯分離開來纔是要緊之事】
MVP模式（模型-視圖-控制器）
Ref: Android Module] 03 - Software Design and Architecture
連接已講。把業務邏輯從Activity中挪出來，挪到Presenter中去，讓Activity迴歸View的角色，今後Presenter專一於業務，View專一於顯示。
業務邏輯再也不受Activity生命週期的影響，Activity也擺脫了業務邏輯沒法複用的囧境。
【先搞定了業務獨立，下一個階段再搞定view和controller的徹底分離】
View懇求Presenter幫忙問問Model是否能給點數據。
Model經過實現回調函數對外提供了一個接口給Presenter。
簡單的講：View調用Presenter的函數，該函數內部調用Model的一個回調函數實現的接口。
[Android Module] 08 - MVP by Mosby
其餘
* MVVM - [Android Module] 06 - DataBinding and MVVM。
* 起源於React的Flux框架。
另外幾種模式
From: 10種常見的軟件架構模式
分層模式
通常信息系統中最多見的是以下所列的4層。
-
- 表示層(也稱爲UI層)
- 應用層(也稱爲服務層)
- 業務邏輯層(也稱爲領域層)
- 數據訪問層(也稱爲持久化層)
Jeff：其實就是傳統模型。
客戶端-服務器模式
典型場景：郵件服務器和瀏覽器的關係
主從設備模式
主設備組件在相同的從設備組件中分配工做，並計算最終結果，這些結果是由從設備返回的結果。
管道-過濾器模式
管道-過濾器模式的體系結構是面向數據流的軟件體系結構。它最典型的應用是在編譯系統。一個普通的編譯系統包括詞法分析器,語法分析器,語義分析與中間代碼生成器,優化器,目標代碼生成器等一系列對源程序進行處理的過程。
Jeff: 有點生僻
代理模式
此模式用於構造具備解耦組件的分佈式系統。
使用場景：消息代理軟件，如Apache ActiveMQ，Apache Kafka，RabbitMQ和JBoss Messaging
點對點模式
在這種模式中，單個組件被稱爲對等點。對等點能夠做爲客戶端，從其餘對等點請求服務，做爲服務器，爲其餘對等點提供服務。對等點能夠充當客戶端或服務器或二者的角色，而且能夠隨時間動態地更改其角色。
使用場景：
-
- 像Gnutella和G2這樣的文件共享網絡
- 多媒體協議，如P2PTV和PDTP
- 像Spotify這樣的專有多媒體應用程序
Jeff: 有點生僻
事件總線模式
相似於消息廣播。
模型-視圖-控制器模式
已閱。
黑板模式
已閱。
解釋器模式
這個模式用於設計一個解釋用專用語言編寫的程序的組件。它主要指定如何評估程序的行數，即以特定的語言編寫的句子或表達式。其基本思想是爲每種語言的符號都有一個分類。
使用場景：
-
- 數據庫查詢語言，好比SQL
- 用於描述通訊協議的語言
每種體系架構模式的優缺點
| 分層模式 |
一個較低的層能夠被不一樣的層所使用。層使標準化更容易，由於咱們能夠清楚地定義級別。能夠在層內進行更改，而不會影響其餘層。 |
不是廣泛適用的。在某些狀況下，某些層可能會被跳過。 |
| 客戶端-服務器模式 |
很好地創建一組服務，用戶能夠請求他們的服務。 |
請求一般在服務器上的單獨線程中處理。因爲不一樣的客戶端具備不一樣的表示，進程間通訊會致使額外開銷。 |
| 主從設備模式 |
準確性——將服務的執行委託給不一樣的從設備，具備不一樣的實現。 |
從設備是孤立的：沒有共享的狀態。主-從通訊中的延遲多是一個問題，例如在實時系統中。這種模式只能應用於能夠分解的問題。 |
| 管道-過濾器模式 |
展現併發處理。當輸入和輸出由流組成時，過濾器在接收數據時開始計算。輕鬆添加過濾器，系統能夠輕鬆擴展。過濾器可重複使用。 能夠經過從新組合一組給定的過濾器來構建不一樣的管道。 |
效率受到最慢的過濾過程的限制。從一個過濾器移動到另外一個過濾器時的數據轉換開銷。 |
| 代理模式 |
容許動態更改、添加、刪除和從新定位對象，這使開發人員的發佈變得透明。 |
要求對服務描述進行標準化。 |
| 點對點模式 |
支持分散式計算。對任何給定節點的故障處理具備強大的健壯性。在資源和計算能力方面具備很高的可擴展性。 |
服務質量沒有保證，由於節點是自願合做的。安全是很可貴到保證的。性能取決於節點的數量。 |
| 事件總線模式 |
新的發佈者、訂閱者和鏈接能夠很容易地添加。對高度分佈式的應用程序有效。 |
可伸縮性多是一個問題，由於全部消息都是經過同一事件總線進行的。 |
| 模型-視圖-控制器模式 |
能夠輕鬆地擁有同一個模型的多個視圖，這些視圖能夠在運行時鏈接和斷開。 |
增長複雜性。可能致使許多沒必要要的用戶操做更新。 |
| 黑板模式 |
很容易添加新的應用程序。擴展數據空間的結構很簡單。 |
修改數據空間的結構很是困難，由於全部應用程序都受到了影響。可能須要同步和訪問控制。 |
| 解釋器模式 |
高度動態的行爲是可行的。對終端用戶編程性提供好處。提升靈活性，由於替換一個解釋程序很容易。 |
因爲解釋語言一般比編譯後的語言慢，所以性能多是一個問題。 |
新潮模式
微內核架構
能夠理解爲
插件模式。
微服務架構
難點在於粒度的肯定，分解項目後各個組件提供獨立的服務。
那麼問題來了，獨立的服務怎麼寫？
ESB
企業服務總線，即ESB全稱爲Enterprise Service Bus，指的是傳統
中間件技術與XML、Web服務等技術結合的產物。ESB提供了網絡中最基本的鏈接中樞，是構築企業神經系統的必要元素。
面向服務的體系結構已經逐漸成爲IT集成的主流技術。面向服務的體系結構(service-oriented architecture，SOA)是一種軟件系統設計方法，經過已經發布的和可發現的接口爲終端用戶應用程序或其它服務提供服務。
做者：徐兵元
首先，能夠確定的是SOA和微服務的確是一脈相承的，大神Martin Fowler提出來這一律念能夠說把SOA的理念繼續昇華，精進了一步。其核心思想是在應用開發領域，使用一系列微小服務來實現單個應用的方式途徑，或者說
微服務的目的是有效的拆分應用，實現敏捷開發和部署 ，能夠是使用不一樣的編程語言編寫。而SOA可能包含的意義更泛一些，更不許確一些。
其次，從實現方式上，二者都是中立性，語言無關，協議跨平臺，相比SOA，微服務框架將可以帶來更大的敏捷性，併爲你構建應用提供更輕量級、更高效率的開發。而
SOA更適合大型企業中的業務過程編排、應用集成。另外還有
微服務甚至是去ESB、去中心化、分佈式的，而SOA仍是以ESB爲核心，大量的WS標準實現。
再次，從服務粒度上，既然是微，必然微服務更倡導
服務的細粒度，重用組合，甚至是每一個操做（或方法）都是獨立開發的服務，足夠小到不能再進行拆分。而SOA沒有這麼極致的要求，只須要接口契約的規範化，內部實現能夠更粗粒度，微服務更多爲了
可擴充性、負載均衡以及提升吞吐量而去分解應用，但同時也引起了打破數據模型以及維護一致性的問題。
最後，從部署方式上，這個是
最大的不一樣，對比Monolithic（有人翻譯爲單體）的Java EE部署架構，經過展示層打包WARs，業務層劃分到JARs最後部署爲EAR一個大包，而微服務則打開了這個黑盒子，
把應用拆分紅爲一個一個的單個服務，應用Docker技術，不依賴任何服務器和數據模型，是一個 全棧應用，能夠經過自動化方式獨立部署，
每一個服務運行在本身的進程中，經過輕量的通信機制聯繫，常常是基於HTTP資源API，這些服務基於業務能力構建，能實現集中化管理（由於服務太多啦，不集中管理就沒法DevOps啦）。
問題 [2] 我所理解的SOA和微服務
微服務其實就是隨着互聯網的發展，複雜的平臺、業務的出現，致使SOA架構向更細粒度、更經過化程度發展，就成了所謂的微服務了。以這種說法作爲根據，我以爲SOA與微服務的區別在於以下幾個方面：
- 微服務相比於SOA更加精細，微服務更多的以獨立的進程的方式存在，互相之間並沒有影響；
- 微服務提供的接口方式更加通用化，例如HTTP RESTful方式，各類終端均可以調用，無關語言、平臺限制；
- 微服務更傾向於分佈式去中心化的部署方式，在互聯網業務場景下更適合；
問題 [3] 誰能用通俗的語言解釋一下什麼是 RPC 框架？
RPC就是要像調用本地的函數同樣去調遠程函數。
Netty框架不侷限於RPC，更多的是做爲一種網絡協議的實現框架，好比HTTP，因爲RPC須要高效的網絡通訊，就可能選擇以Netty做爲基礎。
除了網絡通訊，RPC還須要有比較高效的序列化框架，以及一種尋址方式。
若是是帶會話（狀態）的RPC調用，還須要有會話和狀態保持的功能。
參考學習：Dubbo的網站架構發展圖
- 單一應用架構
- 當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。
- 此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。
- 垂直應用架構
- 當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
- 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
- 分佈式服務架構
- 當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
- 此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
- 流動計算架構
- 當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
- 此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。
平臺隨着業務的發展從 All in One 環境就能夠知足業務需求（以Java來講，可能只是一兩個war包就解決了）；發展到須要拆分多個應用，而且採用MVC的方式分離先後端，加快開發效率；
在發展到服務愈來愈多，不得不將一些核心或共用的服務拆分出來，其實發展到此階段，若是服務拆分的足夠精細，而且獨立運行，我以爲就能夠將之理解爲一個微服務了。
End.