首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >架构设计方法初探

架构设计方法初探

作者头像
Java团长
发布2018-08-03 15:11:27
1740
发布2018-08-03 15:11:27
举报

1. 基本概念和目的

架构设计的目的是为了解决系统复杂度带来的问题,并不是要面面俱到,不需要每个架构都具备高性能、高可用、高扩展等特点,而是要识别出实际业务实际情况的复杂点,然后有有针对性地解决问题,即:有的放矢,而不是贪大求全。 在实际情况中,不一定每个系统都要做架构设计,需要结合实际情况。有时候最简单的设计开发效率反而是最高的,架构设计毕竟要投入时间和人力,这部分投入如果用来尽早编码,项目也许会更快。

2. 架构设计复杂度来源

高性能

高可用

可扩展性

低成本、安全、规模

3. 架构设计三原则

合适原则

GFS为何在Google诞生,而不是在Microsoft诞生,其中Google有那么庞大的数据是一个主要因素,而不是因为Google的工程师比Microsoft的工程师更加聪明。

真正优秀的架构都是企业在当前人力、条件、业务等各方面约束条件下设计出来的,能够合理地将资源整合一起并发挥出最大功效,并且能迅速落地。这也是很多BAT出来的架构师到了小公司或者创业团队反而做不出成绩的原因,因为没有大公司的平台、资源、积累,只是生搬硬套大公司的做法,失败的效率非常高。

简单原则

无论是结构的复杂性还是逻辑的复杂性,都会存在各种问题,所以架构设计时如果简单方案和复杂的方案都可以满足需求,最好选择简单的方案。《UNIX编程艺术》总结的KISS(Keep It Simple,Stupid!)原则一样适用于架构设计。

演化原则

对于软件系统来说,变化才是主题。软件架构需要根据业务的发展而不断变化。 如果没有把握“软件架构需要根据业务发展不断变化”这个本质,在做架构设计的时候就很容易陷入一个误区:试图一步到位设计一个软件架构,期望不管业务如何变化,架构都稳如磐石。

为了实现这样的目标,要么照搬业界大公司公开发表的方案;要么投入庞大的资源和时间来做各种各样的预测、分析、设计。无论哪种做法,后果都很明显:投入巨大,落地遥遥无期。更让人沮丧的是,就算跌跌撞撞拼死拼活终于落地,却发现很多预测和分析都是不靠谱的。

实践中,架构师要提醒自己不要贪大求全,遵循演化优于一步到位的原则,因为业务的发展和变化总是很快的,**无论多牛的团队,都不可能完美预测所有的业务发展和变化路径。**实践中可以参考如下建议:

  • 首先,设计出来的架构要满足当时的业务需要
  • 其次,架构要不断地在实际应用过程中迭代,保留优秀的设计,修复有缺陷的设计,改正错误的设计,去掉无用的设计,使得架构逐渐完善。
  • 第三,当业务发生变化时,架构要扩展、重构,甚至重写;代码也许会重写,但有价值的经验、教训、逻辑、设计等却可以在新架构中延续。

4. 架构设计的流程

原文:juejin.im/post/5b2c6669e51d4558c91ba776

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-06-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Java团长 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 基本概念和目的
  • 2. 架构设计复杂度来源
    • 高性能
      • 高可用
        • 可扩展性
          • 低成本、安全、规模
          • 3. 架构设计三原则
            • 合适原则
              • GFS为何在Google诞生,而不是在Microsoft诞生,其中Google有那么庞大的数据是一个主要因素,而不是因为Google的工程师比Microsoft的工程师更加聪明。
                • 简单原则
                  • 演化原则
                  • 4. 架构设计的流程
                  领券
                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档