识别复杂度

将主要的复杂度问题列出来， 然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题

对于按照复杂度优先级解决的方式，存在一个普遍的担忧：如果按照优先级来解决复杂度，可能会出现解决了优先级排在前面的复杂度后，解决后续复杂度的方案需要将已经落地的方案推倒重来。 这个担忧理论上是可能的，但现实中几乎是不可能出现的，原因在于软件系统的可塑性和易变性。 对于同一个复杂度问题，软件系统的方案可以有多个，总是可以挑出综合来看性价比最高的方案。

即使决定要推倒重来，这个新的方案也必须能够同时解决已经被解决的复杂度问题， 一般来说能够达到这种理想状态的方案基本都是依靠新技术的引入。

例如：Hadoop 能够将高可用、高性能、大容量三个大数据处理的复杂度问题同时解决。

关键指标

• “高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。

  对于常见中间件的性能量级范围：

  nginx负载均衡性能是3万左右，mc的读取性能5万左右，kafka号称百万级， zookeeper写入读取2万以上，http请求访问大概在2万左右。 具体的数值和机器配置以及测试案例有关，但大概的量级不会变化很大。

  关注QPS，TPS可以考量其峰值一般取平均值的 3 倍。 倍数是根据业务发展速度来预估的，不是固定为 3 倍， 不同的业务可以是 2 倍，也可以是 8 倍， 但一般不要设定在 10 倍以上，更不要一上来就按照 100 倍预估。

  如果是业务系统，由于业务复杂度差异很大，有的每秒500请求可能就是高性能了， 因此需要针对业务进行性能测试，确立性能基线，方便后续架构设计做比较。

• “可用性”主要从服务不中断等质量属性，符合行业政策、国家法规等方面去考虑。

• “扩展性”则主要从功能需求的未来变更幅度等方面去考虑。

其他复杂度，例如：”安全”、”成本”等，按照具体情况具体分析。