架构师应该在团队中发挥怎样的作用？

架构师分为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全面，并具有前瞻性视野。