: \. v2 y2 p+ ~
馮大輝：假設一家c2c **，db中某錶儲存買賣雙方交易的資料資訊，對於一條交易來說，買賣雙方資料具有一定程度的耦合性，比如賣家的狀態更新對應買家的狀態也會更新，對於乙個中大規模的電子商務**，架構師在設計中如何考慮資料分片的問題（假定該錶隨著資料的膨脹必須拆分)?
王速瑜：對於乙個中大規模的電子商務**，隨著**的不斷發展，其相應的資料規模會不斷膨脹。資料分片技術是使**得於實現可擴充套件性的一種常用解決方案。對於c2c型別的**，由於交易記錄不容易進行水平的資料分割，因此對於這樣的應用處理要在進行細分：: f8 i! n+ t7 s5 o, w9 n5 x
買賣雙方交易的資訊，具備較高的時效性，即交易全部完成後就不會再有更新，因此這部分資料可以與正在交易中的資料區分開來，並可以單獨分表，定時歸納。具體的做法可以採用水平分割的資料分片技術，比如可以根據使用者號碼段範圍進行切片，把不同的群體劃分到不同的 db 上，這樣可以很好的進行橫向水平擴充套件（scale out）。它可以很好的突破單節點資料庫伺服器的 i/o 能力限制，解決資料庫擴充套件性問題。
對於正在交易中的資料，主要根據時間進行分表。如果分的更細，則可以分三個表，但是這樣在事務保證方面則要複雜很多，不建議這樣做
馮大輝：技術團隊在開發過程中是否進行整合測試? 進行與否的理由各是什麼? 對於整合測試你是否有其他補充?# q4 y$ v" a" [7 s: ]
% p1 x5 i- p {* [$ t4 s
王速瑜：有進行整合測試，因為整合測試對於產品版本的發布是一環重要的保證。但是由於網際網路產品研發的敏捷性，很難建立一套大而全的整合測試平台，而更多還是在功能級和模組級別上的整合測試。% v4 d6 ^; |. e n1 o
- q: ?, [% [# f4 _, d
馮大輝：對於乙個架構師來說，如何與冗雜的會議進行鬥爭? 你有哪些心得或者貴公司有哪些針對會議的策略呢?, f" w; k" w! c. g! y: a
$ b9 o; g# {8 d6 r! l
王速瑜：對於架構師，參加會議是必然的，架構師往往都需要深入到具體的專案中去，在專案的開展過程，大概會有幾類會議是由架構師發起或重點參與的，包括迭代0的架構設計討論會、定期的架構和**review會等等，專案之外，架構師通常還會參加諸如行業級和公司級別的一些盛會和峰會。對於會議，更多還是抱著有益，高效的態度去參加。在實際工作當中，我覺得有以下幾點是可以參考的：
7 b0 g% u* i: t. w. j
涉及架構發展和改進的會議一定要進行， 而且要在產品研發過程中階段性進行。有利於保證架構工作的可持續發展；
由架構師主導的會議，要把握高效會議的原則，包括會議前的充分準備工作、會議程序的把握、會後的關鍵事項跟進等等；
架構師要積極參加產品的討論會，了解產品發展的規劃和細節，有很多架構工作是需要技術與業務相平衡的，參加這樣的會議有利於架構師更好理解業務和它的發展，從而為架構的平衡做出更好的判斷；
架構師要擴充套件視野和保持不斷學習的態度，因此行業技術盛會、公司技術峰會、產品月會等等型別的會議架構師要主動選擇性去參加，可以保證架構師能了解技術趨勢，提公升自己的能力。
不必要的會議盡量不參加，可以採取其他溝通手段，如郵件，im工具來替代，提公升溝通的效率。
4 s5 q3 p. k: ^3 c8 d! o2 n+ b
3 h% ?0 f; t' p6 l" ?: r
馮大輝：架構師是否有必要關注使用者體驗? 如何從架構師的層面關注使用者體驗?
王速瑜：非常有必要。保證使用者體驗是所有軟體最重要的目標，特別是網際網路產品，如果該目標無法實現，再好的架構也沒有存在的意義。因此如何在滿足使用者體驗的前提下進行架構設計是架構師的必要素質。
產品的使用者體驗包括幾個方面：產品的功能便利性、產品可用性、效能、安全性等等。例如：槍戰類的遊戲，需要優先保證其實時性。而在c2c訂單交易中則優先保證其金錢的安全性。因此如何從架構層面就去關注使用者體驗非常重要。對於架構師來說，通常有以下幾點是需要注意的：
) m, y' b" n" @9 ~3 m
$ v: w7 k0 z3 n7 ~
使用者體驗表現在外表，但**與內在。比如網際網路服務的效能設計，能否讓使用者在1秒內使用你的產品，將是保證使用者繼續使用產品的關鍵所在。架構上如何做得在海量使用者的前提下很高的效能，就應該是架構師首要關注的點；
使用者體驗與架構設計有時候會對立矛盾，架構師需要平衡。比如為了某個使用者體驗，可能需要架構上做出重點的調整，可能會帶來巨大的運營成本。這個時候就需要架構師來trade-off了，柔性可用依然是可以採取的架構原則；
一切以使用者體驗和價值為核心是每個架構師在架構網際網路服務的基本準則。網際網路服務不同於傳統軟體，ugc型的網際網路產品更是如此，沒有使用者參與，再好的架構都是無益的，因此架構設計需要圍繞使用者體驗和價值來持續進行。
支付寶架構師 從工程師到架構師的成長之路
架構的技術職責分為三大塊 抽象設計 非功能設計 關鍵技術設計。首先是抽象設計。架構師需要能自由地在不同的抽象層次和視角上分析需求，不同的架構層次 視角提供了不同的檢視，這些檢視互相驗證，又能構成整體的設計大圖。架構的抽象層次分成兩個維度 垂直維度 從上到下，分成企業架構 解決方案架構 應用架構 系統...
支付寶架構
支付寶作為最老牌的支付機構，其支付系統的架構和使用的技術是很值得我們在設計與實現支付系統時作為參考的，這篇文章為大家深度解析支付寶的產品架構。系統架構概況 支付寶的系統採用的是乙個典型的從渠道到產品到服務到支付渠道的應用架構，其中服務根據業務的發展，一方面考慮平衡業務的增長與創新，另一方面考慮系統的...
支付寶首席架構師程立 做架構就像造房打地基
支付寶人物系列之 支付寶首席架構師程立 什麼是架構師？在大多數人看來，這是乙個神秘而充滿技術色彩的稱謂，帶著這個頭銜的都是最頂尖的技術人才。而在支付寶首席架構師程立看來，架構師的工作其實並不神秘，做架構就像造房子要打地基一樣，架構師就是那個為整個 和系統打地基的人。放棄學位，投身 創業 程立的經歷具...