架构学习-架构设计流程

  1. 1. 识别复杂度
  2. 2. 设计备选方案
  3. 3. 评估和选择备选方案
  4. 4. 详细方案设计

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

文章标题:架构学习-架构设计流程

文章字数:1k

本文作者:Leilei Chen

发布时间:2020-02-03, 20:14:02

最后更新:2020-02-03, 20:14:25

原始链接:https://www.llchen60.com/%E6%9E%B6%E6%9E%84%E5%AD%A6%E4%B9%A0-%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1%E6%B5%81%E7%A8%8B/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

目录
×

喜欢就点赞,疼爱就打赏