架構師分為5種：

1.企業架構師EA(Enterprise Architect)? ?EA的職責是決定整個公司的技術路線和技術發展方向。

2.基礎結構架構師IA(Infrastructure Architect)? IA的工作就是提煉和優化技術方面積累和沉淀形成的基礎性的、公共的、可復用的框架和組件，這些都是一個技術型公司傳承下來的最寶貴的財富之一；

3.特定技術架構 TSA (Technology-Specific Architect)? ?主要從事類似安全架構、存儲架構等專項技術的規劃和設計工作；

4.解決方案架構師SA (Solution Architect)。專于解決方案的規劃和設計

5.業務架構師BA (Business Architect)。在業務團隊內部，和leader打配合。

和業務團隊聯系最為緊密的業務架構師，在團隊中，leader和架構師之間一般是劉備和諸葛亮之間的關系。如果leader本身技術能力特別強，那可能會演變成曹操和荀彧。荀彧在戰略方面為曹操規劃制定了統一北方的藍圖和軍事路線，多次修正曹操的戰略方針。

不管是諸葛亮、荀彧，或者其他的架構師例如：張良、羊皮大夫百里奚，在團隊中有兩個重要作用：第一個是制定規范、規劃和方案，第二個是在團隊中有足夠的影響力，在關鍵時刻發揮作用。

那要問影響力是怎么來的，那就是個人技術能力的一個認可度了。前段時間我在做拆庫分表的技術方案評審時，聽到人家說就是現在業務不太忙，想把事情做掉。具體為什么要一拆十還是拍腦袋的，未來誰也說不好。就這件事，我談談自己的觀點。仁者見仁，沒有誰對誰錯，只是談談自己的思考。

為什么要分表？

之所以想著去做這件事，我理解是為了未來解決擴展性的問題。是需要依托于架構整體規劃的。架構整體規劃重要的環節是容量評估。容量評估除了在大的技術方案上要考慮之外，一般還需要架構師定期去做。比如1個季度、半年、1年做一次容量評估。

未來的不確定因素太多，容量怎樣去評估呢？

我們的目標是什么。如果目標是同行業前5。可以從他們公開的財務報表等數據調研他們的數據量級。比如行業第五，日單量是500萬。拆10張表。一個數據庫在量級達到千萬級別，性能開始下降。也就是說1張表大概可以存2天的數據，10張表可以存20天的數據。數據歷史記錄如果可以允許查半年的。那就不夠了。分成100張表，過了半年可以進行歸檔，就可以持續支撐日單量500萬的交易。

實際上一般很少有人要做分庫分表了，一次這種大動作還只提高10倍的容量。因為就單庫來說，分成1百張表、1千張表，磁盤容量都不是瓶頸。瓶頸在支撐的TPS上。就一個高性能物理機的數據庫來說，大概可以支撐5000TPS量級。在這種情況下，表分的細一些，可以提高單表的性能。況且，這種邏輯分表并不需要額外的資源支持，不會增加成本。

容量評估時還需要考慮哪些因素？

容量評估時還需要考慮其他的設計：讀寫分離、數據歸檔。

讀寫分離，如果讀寫比例是1比1，分離后容量會增加1倍。但分離和不分離的區別不是簡單改代碼的問題，而是分離后要考慮讀的延遲。比如mysql主從延遲一般在1s。實時業務的場景其實不能夠允許這么大的延遲。但有些場景，比如歷史查詢、列表查詢是可以的。如果讀寫分離是需要想清楚哪些場景要拆分到主庫，哪些是拆分到從庫的。會不會涉及事務問題。

數據歸檔，因為已經需要使用像sharding-jdbc這種中間件了。這種中間件不僅可以支持哈希散列算法，還可以按照時間散列的。所以可以直接在分表設計時就可以設計為_上半年下半年標識_哈希，這樣只要有定時腳本數據表直接提前建好，自動實現數據歸檔，無需額外服務處理。比如現在已經是下半年。現在上半年只有讀的流量，沒有寫的流量了。下半年的讀寫都很多。所以上半年數據屬于冷數據，下半年數據屬于熱數據，實現了冷熱分離。

其他還有什么考慮點？

數據庫分庫分表是個大動作，一般要提前很久規劃，過程因為涉及數據一致性校驗等環節，相對持續時間也很長。而這個過程是對業務進行梳理的絕佳機會。比如可以趁此機會將原本的數據庫事務改成分布式事務，提升架構的性能和擴展性。

而架構師要自己或者帶領團隊成員做好各個方面的考慮。考慮問題要比leader全面，并具有前瞻性視野。