最近在做交易雲服務介面，對接各個業務方的時候，存在一些爭議。業務方認為，一些營銷、物流相關的資訊應當由交易來封裝返回，而交易則認為這些資訊並不是自己所關心的，應當由業務方根據自己的需要去對應的基礎服務介面獲取和定製。 公說公有理婆說婆有理，我個人的觀點如下：
首要是關注點。誰去呼叫誰，只是個小的技術細節。靈活組合基礎服務介面上玩出有潛力的業務，才是真正要關心的事情啊！
對於業務方來說，基礎服務介面提供的是最基本的土壤和水的作用，而不是酸性或鹼性的施了某種肥料的土壤，是高穩定、高吞吐量、高流暢的、極低bug率的正交的聚焦於自身領域的服務，而不是一時便利的一條龍服務。應該賦予業務方強大的可組合的、依賴乾淨的服務。
想想，如果在 find 裡加點 grep 的功能，或者在 grep 裡加點 find 的功能，固然在初始時能帶來方便，可是發展到複雜任務的時候，程式會變慢、不穩定、bug率上公升、依賴關係錯綜複雜，你期望勤懇耕耘的時候腳底下不時震一震麼？
上聖，民不知其有；上明，民感其恩德。基礎服務介面應當盡量做到用過就像不存在一樣，而不是時不時來找公升級。
摻雜了其他資訊的雜燴性介面有什麼利處和弊端呢？
利處明顯，方便了業務方的使用，讓業務方省了一時的心。
弊端也很明顯。假設業務方x依賴介面a。
(1) 介面a原本是30ms 返回，呼叫另乙個 30ms 的介面b獲取額外資訊，那麼其吞吐量就會降低一半；如果 b 超時，那麼還會導致 a 的響應和吞吐量進一步降低，甚至服務不穩定；
(2) 當b因為某個業務方x需要公升級時，a也要同步公升級以供x使用，而依賴a的其他業務方並不需要這個公升級，卻受到了牽連影響；假設 a 因為某種原因不能及時公升級，業務方x的產品進度就會受到影響；
(3) 不必要的測試與溝通成本。若 a 依賴 b，那麼聯調時，當 b 出現問題時，無論是否為 a 的問題， a 都需要去找 b 去修復，存在比較大的傳遞溝通成本； 若 x 分別依賴 a 與 b ，那麼 a 提供足夠穩定高效的服務介面。 b 有問題，讓 x 與 b 單獨溝通去， a 可專注於解決自身領域的問題。測試亦存在傳遞測試成本。
(4) 不必要的依賴。 x 依賴 a ， a 依賴 b， 而原本 a 與 b 是平行的關係，這樣在底層又增加了不必要的服務依賴關係，久而久之，就形成錯綜複雜的依賴網，走回原來的老路了。
(5) 小而美的介面足夠穩定足夠快，快到bug還沒反應過來就已經返回結果啦； 而摻雜了其他資訊的介面則給bug留下了反應過來的時間。
do less, done more.
如果有5個高穩定性的能以30ms返回的小而美的介面，以及2個融合了其它資訊的可能不穩定的雜燴介面，我寧願選擇第一種。呼叫介面只是幾行**的事情，靈活而強大才是長遠之選。貪圖一時便利，正是埋下禍患之時。
乾淨、正交的服務，就像設計優良的拼板，有雄心的業務方理解每個拼板的能力和潛力，想辦法拼出巨集大的版圖，而基礎服務介面提供的，就是讓每一塊拼板美觀、流暢、牢固、耐用、完全可放心使用。
小而美，組合才是力量之源。
馬雲 因小而美
全球經濟衰退的來襲令許多國際企業都頻臨倒閉，去年關於此類事件的新聞報道層出不窮。但這並非當今時代的標誌，反而，它預示著一場嶄新的商業革命正徐徐拉開序幕。這些大企業中有許多都是從上世紀踉蹌走到今天，而金融危機則給它們帶來了致命一擊，令其固有缺陷暴露無遺。今時今日，一場由網際網路技術掀起的革命正初露端倪...
傅利葉變換的實質 正交之美
引 最近在搞乙個音訊解碼器，將隨意錄製好的聲音按照不同的頻率分離出不同的音訊流，然後推到不同的音箱中，如果再考慮一下音場的諧性，那就是乙個n.1聲道的解碼系統了。我只是想在女兒 或者兒子 出生之前為她做點事情，以便能最終做出個東西送給她 或者他 在實踐的過程中，遇到了傅利葉變換，作文以記之。最終我會...
分碼多重進接 CDMA 的本質 正交之美
原文 引 最近在搞乙個音訊解碼器，將隨意錄製好的聲音按照不同的頻率分離出不同的音訊流，然後推到不同的音箱中，如果再考慮一下音場的諧性，那就是乙個n.1聲道的解碼系統了。我只是想在女兒 或者兒子 出生之前為她做點事情，以便能最終做出個東西送給她 或者他 在實踐的過程中，遇到了傅利葉變換，作文以記之。最...