好玩的网站列表

1. 识别复杂度

具体情况需要具体分析，即这个系统的复杂度体现在哪一个方面。一个系统的复杂度主要来源于高性能，高可用，可扩展这几个方面。

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

多个系统之间的强耦合，可以通过信息队列来解耦。要注意从高可用，高性能，可扩展几个维度对其进行分析，看整个架构调整的复杂度在哪里，然后做针对性的提升。

平均TPS， QPS，峰值TPS (average x 3)，

2. 设计备选方案

架构师需要对已经存在的技术非常熟悉，对已经经过验证的架构模式烂熟于心，然后根据自己对于业务的理解，挑选合适的架构模式进行组合，再对组合之后的方案进行修改和调整。

目前，只要明确了应用场景，复杂度上的限制因素，我们往往能找到相对成熟的技术来直接使用。例如

• 高可用主备方案
• 集群方案
• 高性能负载均衡
• 多路复用
• 可拓展的分层
• 插件化技术

设计备选方案的tips

• 多设计几个备选方法，3-5个为宜
• 方案之间的差异要比较明显
• 备选方案的技术不要只局限于已经熟悉的技术
• 备选方案不需要太过于详细的，关注的是技术选型，而不是技术细节

对于高性能写入

• 集群
• 直接写入一台正常的服务器即可
  高可用存储
• 已经写入的信息在单台服务器宕机的情况下不丢失
• 使用MySQL的主备复制功能
  高可用读取
• 要求已经写入的消息在单台服务器宕机的情况下可以继续读取
• 服务器的主备方案

3. 评估和选择备选方案

• 多角度环评
  • 列出需要关注的质量属性点
  • 分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案
• 方案质量属性点
  • 性能
  • 可用性
  • 硬件成本
  • 项目投入
  • 复杂度
  • 安全性
  • 可拓展性
• 对于需要评估未来业务发展的规模时，一般可以将当前的业务规模乘以2-4 即可。
• 将质量属性按照优先级排序

4. 详细方案设计

将方案涉及的关键技术细节给确定下来。

• 假如我们确定使用 Elasticsearch 来做全文搜索，那么就需要确定 Elasticsearch 的索引是按照业务划分，还是一个大索引就可以了；副本数量是 2 个、3 个还是 4 个，集群节点数量是 3 个还是 6 个等。
• 假如我们确定使用 MySQL 分库分表，那么就需要确定哪些表要分库分表，按照什么维度来分库分表，分库分表后联合查询怎么处理等。
• 假如我们确定引入 Nginx 来做负载均衡，那么 Nginx 的主备怎么做，Nginx 的负载均衡策略用哪个（权重分配？轮询？ip_hash？）等。
  • 轮询
  • 加权轮询 - 后端服务器性能不均
  • ip_hash - 每个方可固定访问同一个后端服务器，解决session的问题
  • fair - 按照响应时间来分配请求，响应时间短的优先分配，能够最大化平衡各后端服务器的压力，可以适用于后端服务器性能不均衡的情况
  • url_hash - 每个url定向到同一个后端服务器，适用于后端服务器能够将url的响应结果缓存的情况

• 通过分步骤，分阶段，分系统等方式，尽量降低方案的复杂度。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com