要點：
架構師首先應該從使用者的角度看軟體的
performance
（表現）。在架構設計上，介面應該足夠靈活，對軟體的
performance
（效能）引數能夠動態調整，以期達到一定自適應的效果。同時總體的架構設計應該考慮到移植性。
討論：優化絕對不是為了技術優化而優化。架構師首先要清楚軟體所要達到的使用者期望目標。這裡以乙個
omap850
（200mhz arm926ej cpu
300kbps h.264 baseline+48kbps aac+v1
可以做到
audio
流暢，video
達到20-25fps
（frames per second
）。這是個基本目標。這個目標完全是從使用者體驗的角度來考慮的。使用者可以接受
video
降低到15fps
，但是不能容忍
audio
的停頓。使用者可以接受
video
的quality
降低，但是不能容忍
audio
，video
的不同步。這些都是架構師要考慮的要點。在設計上，就要適當提高
audio
執行緒的優先順序，要有丟幀的機制用於調整
video
的fps
，對h.264
，要有關閉
deblock
功能的機制，同樣對於
aac+v1
，要有sbr
的開關。所有這些，都要求模組的介面要足夠靈活，不僅能夠在執行時動態調整效能，也能夠擴充套件新的需求。另外在全域性控制上，如執行緒優先順序的調整，
fps的控制，應該具有一定自適應的能力，
架構設計上的這種彈性正是為了保證軟體的
performance
（表現）能夠達到使用者的心理期望值。設計的本質就是一種權衡，是各類相互制約的模組間的一種權衡。明白這一點，就要求架構設計上對各個模組應有靈活的控制，以保證使用者期望目標為設計出發點，平衡各類資源的使用。
color
conversion
硬體加速器的裝置上，如果原先的
color conversion
模組的介面設計的好，就可以不用改動介面，或者只有一點簡單的改動就可以將模組替換掉。
這裡的問題好像轉移倒可移植性去了，在嵌入式開發中，可移植性應該是架構師嚴肅思考的問題。面對不同的
cpu，不同的
os，不同的硬體加速裝置，架構的設計應該有足夠的彈性去容納這些變化。
可移植性強調了通用，而高效的優化是
localize
的。平衡這個矛盾需要良好的設計。上層模組不能依賴於下層實現，下層模組不能依賴於上層實現，上下層都要依賴於抽象，這就是設計中的依賴倒置原則
(dependency inverse principle)
。總體的架構概念，或者說模組間的關係，模組的介面都是封閉的，固定的，而模組的實現是開放的，擴充套件的，這就是設計中的開閉原則（
open/close principle
）。這兩個原則是保證軟體的可移植性的基礎。
可移植性主要包括
cpu級移植和
oscodec
和color conversion
模組基本上是
cpu相關，而和
osframework
，則主要是
os相關而與
cpu無關。對單純
cpu相關的模組比較容易處理，在
item 15
中我們會討論這一類模組的移植問題。至於
os相關的部分，或者我們通常說的
ap層，移植性的問題則需要非常仔細的考慮，和
os緊密相關的
api如
socket
，thread，ui
等 都要考慮增加乙個
adapter
層，可以考慮定製使用第三方的跨平台類庫。
設計快取架構時需要考慮的因素總結
在設計架構快取的時候，首先要選定快取元件，比如要用local cache，還是redis memcached pika等開源快取元件。如果業務快取需求比較特殊，還要考慮是直接定製開發乙個新的快取元件，還是對開源快取進行二次開發，來滿足業務需要。確定好快取元件後，要根據業務訪問的特點，進行快取資料結構...
架構篇 URI設計原則
author simon 優雅型 羅浮宮 達文西 蒙娜麗莎 中庸型 北京 新聞頻道 新聞id 謝特型 斜槓分隔符 必須用於顯示層次關係正例 反例 使用 提高uri的可讀性正例 禁止在url中使用 目的是提高可讀性，可能被文字檢視器中的下劃線特效遮蔽 反例 禁止使用大寫字母rfc 3986中規定uri...
Flink篇 架構設計介紹
從架構的層面 分為無界流和有界流 無界流資料 有定義流的開始，但沒有定義流的結束。它們會無休止地產生資料。無界流的資料必須持續處理，即資料被攝取後需要立刻處理。我們不能等到所有資料都到達再處理，因為輸入是無限的，在任何時候輸入都不會完成。處理無界資料通常要求以特定順序攝取事件，例如事件發生的順序，以...