03-架构设计的目的
0103. 架构设计的目的
谈到架构设计，相信每个技术人员都是耳熟能详，但如果深入探讨一下，「为何要做架构设计？」或者「架构设计目的是什么？」类似的问题，大部分人可能从来没有思考过，或者即使有思考，也没有太明确可信的答案。
关于架构设计的目的，常见的误区有：
因为架构很重要，所以要做架构设计
这是一句正确的废话，架构是很重要，但架构为何重要呢？
例如：不做架构设计系统就跑不起来么？
其实不然，很多朋友尤其是经历了创业公司的朋友可能会发现，公司的初始产品可能没有架构设计，大伙撸起袖子简单讨论一下就开始编码了，根本没有正规的架构设计过程，而且也许产品开发速度还更快，上线后运行也还不错。
例如：做了架构设计就能提升开发效率么？
也不尽然，实际上有时候最简单的设计开发效率反而是最高的，架构设计毕竟需要投入时间和人力，这部分投入如果用来尽早编码，项目也许会更快。
例如：设计良好的架构能促进业务发展么？
好像有一定的道理，例如设计高性能的架构能够让用户体验更好，但反过来想，我们照抄微信的架构，业务就能达到微信的量级么？肯定不可能，不要说达到微信的量级，达到微信的 1/10 做梦都要笑醒了。
不是每个系统都要做架构设计吗
这其实是知其然不知其所以然，系统确实要做架构设计，但还是不知道为何要做架构设计，反正大家都要做架构设计，所以做架构设计肯定没错。
这样的架构师或者设计师很容易走入生搬硬套业界其他公司已有架构的歧路，美其名曰「参考」「微改进」。一旦强行引入其他公司架构后，很可能会发现架构水土不服，或者运行起来很别扭等各种情况，最后往往不得不削足适履，或者不断重构，甚至无奈推倒重来。
公司流程要求系统开发过程中必须有架构设计
与此答案类似还有因为「架构师总要做点事情」，所以要做架构设计，其实都是舍本逐末。因为流程有规定，所以要做架构设计；因为架构师要做事，所以要做架构设计，这都是很表面地看问题，并没有真正理解为何要做架构设计，而且很多需求并不一定要进行架构设计。如果认为架构师一定要找点事做，流程一定要进行架构设计，就会出现事实上不需要架构设计但形式上却继续去做架构设计，不但浪费时间和人力，还会拖慢整体的开发进度。
为了高性能、高可用、可扩展，所以要做架构设计
能够给出这个答案，说明已经有了一定的架构经历或者基础，毕竟确实很多架构设计都是冲着高性能、高可用…… 等「高 XX」的目标去的。
但往往持有这类观点的架构师和设计师会给项目带来巨大的灾难，这绝不是危言耸听，而是很多实际发生的事情，为什么会这样呢？因为这类架构师或者设计师不管三七二十一，不管什么系统，也不管什么业务，上来就要求「高性能、高可用、高扩展」，结果就会出现架构设计复杂无比，项目落地遥遥无期，团队天天吵翻天…… 等各种让人抓狂的现象，费尽九牛二虎之力将系统整上线，却发现运行不够稳定，经常出问题，出了问题很难解决，加个功能要改 1 个月…… 等各种继续让人抓狂的事件。
架构设计的真正目的
那架构设计的真正目的究竟是什么？
从周二与你分享的架构设计的历史背景，可以看到，整个软件技术发展的历史，其实就是一部与「复杂度」斗争的历史，架构的出现也不例外。简而言之，架构也是为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的历史背景和原因，我们可以基本推导出答案：架构设计的主要目的是为了解决软件系统复杂度带来的问题。
这个结论虽然很简洁，但却是架构设计过程中需要时刻铭记在心的一条准则，为什么这样说呢？
首先，遵循这条准则能够让「新手」架构师心中有数，而不是一头雾水。
新手架构师开始做架构设计的时候，心情都很激动，希望大显身手，甚至恨不得一出手就设计出世界上最牛的 XX 架构，从此走上人生巅峰，但真的面对具体的需求时，往往都会陷入一头雾水的状态：
「这么多需求，从哪里开始下手进行架构设计呢？」。
「架构设计要考虑高性能、高可用、高扩展…… 这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间」。
「业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？」。
以上类似问题，如果明确了「架构设计是为了解决软件复杂度」原则后，就很好回答。
「这么多需求，从哪里开始下手进行架构设计呢？」
—— 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
「架构设计要考虑高性能、高可用、高扩展…… 这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间」
—— 架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
「业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？」
—— 理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。
其次，遵循这条准则能够让「老鸟」架构师有的放矢，而不是贪大求全。
技术人员往往都希望自己能够做出最牛的东西，架构师也不例外，尤其是一些「老鸟」架构师，为了证明自己的技术牛，可能会陷入贪大求全的焦油坑而无法自拔。例如：
「我们的系统一定要做到每秒 TPS 10 万」。
「淘宝的架构是这么做的，我们也要这么做」。
「Docker 现在很流行，我们的架构应该将 Docker 应用进来」。
以上这些想法，如果拿「架构设计是为了解决软件复杂度」这个原则来衡量，就很容易判断。
「我们的系统一定要做到每秒 TPS 10 万」
—— 如果系统的复杂度不是在性能这部分，TPS 做到 10 万并没有什么用。
「淘宝的架构是这么做的，我们也要这么做」
—— 淘宝的架构是为了解决淘宝业务的复杂度而设计的，淘宝的业务复杂度并不就是我们的业务复杂度，绝大多数业务的用户量都不可能有淘宝那么大。
「Docker 现在很流行，我们的架构应该将 Docker 应用进来」
——Docker 不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂度根本不是在这方面，引入 Docker 没有什么意义。
简单的复杂度分析案例
我来分析一个简单的案例，一起来看看如何将「架构设计的真正目的是为了解决软件系统复杂度带来的问题」这个指导思想应用到实践中。
假设我们需要设计一个大学的学生管理系统，其基本功能包括登录、注册、成绩管理、课程管理等。当我们对这样一个系统进行架构设计的时候，首先应识别其复杂度到底体现在哪里。
性能：一个学校的学生大约 1 ~ 2 万人，学生管理系统的访问频率并不高，平均每天单个学生的访问次数平均不到 1 次，因此性能这部分并不复杂，存储用 MySQL 完全能够胜任，缓存都可以不用，Web 服务器用 Nginx 绰绰有余。
可扩展性：学生管理系统的功能比较稳定，可扩展的空间并不大，因此可扩展性也不复杂。
高可用：学生管理系统即使宕机 2 小时，对学生管理工作影响并不大，因此可以不做负载均衡，更不用考虑异地多活这类复杂的方案了。但是，如果学生的数据全部丢失，修复是非常麻烦的，只能靠人工逐条修复，这个很难接受，因此需要考虑存储高可靠，这里就有点复杂了。我们需要考虑多种异常情况：机器故障、机房故障，针对机器故障，我们需要设计 MySQL 同机房主备方案；针对机房故障，我们需要设计 MySQL 跨机房同步方案。
安全性：学生管理系统存储的信息有一定的隐私性，例如学生的家庭情况，但并不是和金融相关的，也不包含强隐私（例如玉照、情感）的信息，因此安全性方面只要做 3 个事情就基本满足要求了：Nginx 提供 ACL 控制、用户账号密码管理、数据库访问权限控制。
成本：由于系统很简单，基本上几台服务器就能够搞定，对于一所大学来说完全不是问题，可以无需太多关注。
还有其他方面，如果有兴趣，你可以自行尝试去分析。通过我上面的分析，可以看到这个方案的主要复杂性体现在存储可靠性上，需要保证异常的时候，不要丢失所有数据即可（丢失几个或者几十个学生的信息问题不大），对应的架构如下：
学生管理系统虽然简单，但麻雀虽小五脏俱全，基本上能涵盖软件系统复杂度分析的各个方面，而且绝大部分技术人员都曾经自己设计或者接触过类似的系统，如果将这个案例和自己的经验对比，相信会有更多的收获。
小结
今天我为你分析了架构设计的误区，结合周二讲的架构设计的历史背景，给出架构设计的主要目的是为了解决软件系统复杂度带来的问题，并分析了一个简单复杂度的案例，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧。请按照「架构设计的主要目的是为了解决软件复杂度带来的问题」这个指导思想来分析一下你目前的业务系统架构，看看是否和你当时分析的结果一样？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）
最后给你推荐一个课程，极客时间新上线了《Java 核心技术 36 讲》，由 Oracle 首席工程师杨晓峰老师给你精讲大厂 Java 面试题，帮你构建 Java 知识体系，你可以点击下方图片进入课程。
将学到的知识总结成笔记，方便日后快速查找及复习
unpreview
© 版权归极客邦科技所有，未经许可不得传播售卖。页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
大龙
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
Command + Enter 发表
0/2000 字
提交留言
精选留言 (219)
公号 - 技术夜未眠
架构是为了应对软件系统复杂度而提出的一个解决方案。个人感悟是：架构即 (重要) 决策，是在一个有约束的盒子里去求解或接近最合适的解。这个有约束的盒子是团队经验、成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体 (人，财，物，时间，事情等)。架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。
需求驱动架构。在分析设计阶段，需要考虑一定的人力与时间去 “跳出代码，总揽全局”，为业务和 IT 技术之间搭建一座 “桥梁”。
架构设计处于软件研制的前期，一方面，越是前期，如有问题，就能够越早发现，修改的代价也就越低；另外一方面，也意味着，软件实施后期若有架构上的修改，也需要付出更多的代价。
今日得到:
1 架构是为了应对软件系统复杂度而提出的一个解决方案。
2 架构即 (重要) 决策
3 需求驱动架构，架起分析与设计实现的桥梁
4 架构与开发成本的关系
作者回复：收下我的膝盖，大神写个心得就已经把我后面的内容剧透了，6666👍👍😃
2018-05-03
李志博
今天读完文章，思考了下我们系统的复杂点，我们系统是一个承上启下的系统，根本没自己的表，所有数据都是调第三方接口取，然后汇总聚合给前端浏览器，突然明白最近老大为什么要搞 es 去异步聚合第三方数据了，这样以往我们需要调第三方多次接口取的数据，以后调自己 es 查询一次就可以了，这样性能更高，且逻辑更简单，更容易维护，以往优化这种性能问题的方式，就是多线程，然而多线程也是要消耗资源调，而且代码反而更难以理解，原来最好的优化方式不是把串行变并行，而是把串行干的多个事的数量去减少，首先要根据系统复杂点想到合适的解决方案，其次才是用什么优秀的框架叫代码更牛逼一点，否则一开始就算错的
作者回复：你已经参透天机👍👍
2018-05-03
gevin
我觉得做软件架构是为两件事服务的：业务架构和业务量级，这应该算是「软件系统复杂度带来问题」的具体化吧。
业务架构和业务量级都是从每个具体项目的实际应用场景中提炼出来的。
业务架构是对业务需求的提炼和抽象，开发软件必须要满足业务需求，否则就是空中楼阁。软件系统业务上的复杂度问题，可以从业务架构的角度切分工作交界面来解决。设计软件架构，首先是要保证能和业务架构对的上，这也是从业务逻辑转向代码逻辑的过程，所以软件架构的设计为开发指明了方向。另外架构设计也为接下来的开发工作分工奠定了基础。
业务量级表现在存储能力、吞吐能力和容错能力等，主要是软件运维期业务的复杂度。做软件架构设计，是要保证软件有能力托起它在业务量级上的要求的，如果软件到运行使用期废了，前面所有的工作都付诸东流了。不同的业务量级，对应的软件的架构复杂度是不同的，所以对于不同的项目，业务量级不同，架构设计也不同。
做业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必须先设计软件架构，试图不经分析直接套用先前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重来，更不要说直接拿别人的现成架构方案了。
所以每个软件在开发前，都要结合自己的应用场景设计适合自身的软件架构，现成的架构方案只能借鉴，不能直接套用。
另外，由于业务架构和业务量级也会不断调整或长大，软件架构也不是一劳永逸的，会随业务不断调整。
作者回复：赞，写的很好，对我的专栏内容是很好的补充
2018-05-18
张玮 (大圣)
问答引导式由浅入深来讲解很赞
一个简单的例子能说明相关问题也很赞，就是这样，大家有时不需要大而全的大公司大例子，反手一个赞，加油，运华兄
作者回复：一起加油，大圣✊✊
2018-05-03
霍潘
这篇内容完全符合我们公司目前现状，为了架构而架构。原本 3 个人负责的 nodejs 系统现在改用 JAVA 开发，光架构师招了快 7，8 个。不到 2000 人使用的系统没有一天不出点小故障，开发过程更是痛苦，三天两头的开发环境跑不起来。说是微服务，不过是把原来单体结构按功能拆分，按层级拆分，本来就拆分的够多了，为了开发要启动很多服务。每个新来的架构师都要引入一套自己的架构，结果可想而知
作者回复: 8 个架构师？太夸张了，一个架构师一般可以支撑 20 人以上的开发团队，你们的架构师莫非是传说中的 PPT 架构师？😃
2018-05-03
懒人闲思
伟大导师马克思说过：主要矛盾处于支配地位，次要矛盾。。。也会有影响，架构设计就是提前预判可能遇到的矛盾，用最小的代价解决它
作者回复：用马哲来指导架构设计，好像也有道理😃
2018-05-03
✎﹏๓₯㎕╮陌
架构就是。当你想拉屎的时候首先得去找厕所。选择一个什么样的厕所。
距离选择。如果太远可能就漏出来了
成本选择。如果拉屎太贵也不合适
性能选择。好的厕所可以拉的心情舒畅
作者回复：角度刁钻😂😂
2018-05-05
suke
老师好，我们目前在做内部的对象存储中控台，满足的需求有以下几个:
方便内部非开发人员做数据存储
提供对象存储的图形化界面
监控整个存储集群的存储相关的指标，例如存储量，下行流量、api 调用等等
这几个需求也算是我结合公司的现有业务状况，以及对象存储的特性，自己总结的。
系统上线以后，我预计的使用情况如下:
大的天使客户都是一些职能的业务部门，由存储集群提供底层的存储接口，通过中控台进行监控，图形化操作
其他零散人员，可存储一些工作上的数据
目前我只是做了个 demo 出来，整体架构:nginx 做前端的负载，springboot 提供服务，mysql 存储元数据，redis 做消息队列，以及缓存，数据通过接口传到存储集群
这个架构也没做太多考虑，就像老师您说的情况一样，只不过公司其他的系统也差不多都这样。
对象存储中控台的业务复杂度我思考有以下几个:
提供高可用，高性能的上传下载功能
提供 bucket 以及对象的查询功能
提供低延迟的监控统计功能
并发访问量个人感觉都集中在存储集群的接口调用，中控台这边并不高，但是一定要做到系统的高可用，保证内部职工正常的工作使用，同时 mysql 也要做到主备和异地多活，以及 redis 的主备
老师这样的分析可以么，针对这样的业务，现有的架构有问题么
作者回复：你分析的主要还是功能点，应该更进一步，分析这些功能点后的复杂度，而且要尽量量化。例如：
高可用和高性能：到底要多高，为什么要高性能高可用？
低延迟：到底多低？秒级和分钟级和小时级，复杂度差很大，秒级你可能要用流式计算，分钟级用后台计算可能就可以了，小时级直接用数据库就可以了
系统高可用具体达到什么水平？是 1 分钟都不能停，还是可以停 1 个小时？是数据绝对不能丢，还是可以丢一部分数据然后其它方式修复？
对于高性能和高可用，千万不能说越高越好，一定要结合业务，例如，绝大部分内部系统的宕机容忍时间可以是一个小时。
2018-05-03
追梦
赞，就是不要过度设计，架构设计要贴合业务，找到适合能解决业务复杂度的设计，才是好的架构设计
2018-05-03
Will
架构是解决复杂度的问题。那么复杂度有很多不同的来源，比如人（不同的代码风格，不同的编程习惯），比如业务，比如技术。那么架构不可能面面俱到的解决所有问题，必须要分析出所面对的一个或几个关键的问题，这样架构的设计就能有落脚点，而且问题解决也不会有大的冲突。
架构设计在发展的不同阶段面临不同的问题，例如我们公司刚开始就做了业务拆分，后端是多个服务，前端一个站点，并且提供了一个服务互相调用的公共代理，现在主站越来越庞大，涵盖的业务越来越多，所以要做业务拆分，公共代理所包含的服务也越来越多，也要进行拆分。另外一个业务要调用多个服务，如何去监控调用链的完整性，这也需要解决。
所以架构本身在不同阶段集中解决几个最主要的问题，之后随着业务，技术，问题的不断变化，架构的重点也在不断调整。
作者回复：你已经参透天机，后面会讲到你说的内容。
2018-05-04
@漆～心 endless
一切脱离业务的架构设计都是耍流氓
2018-05-03
晴天
我不是架构师，但是有一颗这样的梦想。小时不识月的时候，以为架构就是 ssm，就是几种中间件的堆砌，简单粗暴，我上我也行的心态，后来接触的越多，业务复杂了，又开始忧来其如何了，为什么要这么设计，为什么用这个，接触概念也越来越高大上，开始如作者所说的大牛都该展现自己的技术，就是要上高性能高并发等等，就是要往复杂了去设计，盲目的去崇拜复杂的设计，而恰恰忽略了设计的本质是为了解决一定范围内的问题也就是软件复杂度，其实没必要那么疯狂，也没那么简单。适合的才是最完美的，脱离不了业务，也离不开现实，譬如成本控制，进度控制等等。所以我应该静下心来，认真的去学习那些优良的设计的背后，如何在选择上驾轻就熟，如何在这个规则里游刃有余……
作者回复：现在的你就是曾经的我，一起加油👍👍👍
2018-05-04
罗烽
架构设计主要是为了解决软件复杂度的问题：
现有业务复杂度分析：
性能： 提供外部接口，对性能有一定的要求，对对存储也有一定要求，但访问量每天不高，1 万～2 万，mysql + 缓存，还是有必要的，量不高，但要快
可扩展性：因为需要经常对接其他支付接口，所以这里的可扩展性有一定要求
高可用：这是重点，因为是提供给商场使用的支付接口，哪怕一分钟宕机都是不行的，针对高可用方案，我现在只能想到，在不同机器上部署多套服务，然后用 nginx 做负载。不过晚上没有交易，可以停机的。存储数据都是订单，这个很重要，因为每天需要查账，不过已经使用了阿里云的 rds 主备方案，这里也不用担心
安全性：现在接口都是用 sign 验签，而秘钥都是独立的，所以这里也没有问题了
综合来说，我们对高可用，稳定性是要求最多的，这是这里的复杂度
作者回复: 1. 每天 1~2 万的话，性能要求其实很低，性能都是按秒计算的，所以缓存不一定需要
- 分析的很好，白天要求高，晚上可以停机，这样的背景可以设计很多有趣的方案，例如每天晚上定时重启一次，晚上批处理对账等
2018-05-03
重剑
感觉自己好笨，看了好几章，说不出什么心得体悟😅，看各位大神踊跃发言好羡慕。
作者回复：学完你也可以吹水了😃
2018-05-18
天使
需要一个解决方案降低微服务的实施成本，创业公司面临的主要是需求变化剧烈的问题。微服务可以将变化局限在某个区域，不至于影响全局，所以最好一开始设计的时候就这样设计。我经历了三家创业公司，第一家大泥球架构，半年后就发现改动起来各种痛苦，牵一发动全身有时。第二家第三家上来就是微服务，基本没有这个问题。而且需求不同，可以采用完全不同的技术栈。相比第一家创业公司，人更少了，问题更少了，质量也更高了。另外，没有 devops 搞微服务就是天坑…
作者回复：微服务有专门章节阐述
2018-05-03
Snake
一直有个疑问，一个项目已经在持续推进，而当前的每个迭代只是不停地增加新的业务功能，一般不涉及任何底层设施的变动，此时架构师一般都应该做些什么？是需要针对每个迭代的需求做业务架构设计，然后产出对应的代码架构图吗？如业务的活动图和类图等
作者回复：这个不需要架构师设计，开发人员设计就可以，架构师需要关注项目架构是否会因为开发新业务而引入新的复杂度
2018-05-19
何鹏
我要提问，容我问个题外问题，问题如下。
背景：我工作 3 年多，最近在学习 uml，但是感觉程序设计帮助并不大。程序设计和编程还是靠经验和加班加出来的。
所以问题是，方法论这个东西在程序设计方面真的作用大吗？编程是不是还就是靠经验和加班？
不知道版主哥对方法论怎么看的，并且你用 uml 吗？
补充，uml 我才用了 3 个月，只用它开发了 3 个功能，所以也可能是我资历太浅，没掌握要领和精髓。
作者回复：我的第一本书《面向对象葵花宝典》详细阐述了面向对象全流程的设计方法以及 uml 的应用场景，uml 和架构设计一样，都是有具体应用场景的。
方法论非常有用，编程发展几十年了，方法论就是各路大牛，各种场景的经验总结，你再怎么加班，都不可能把所有的坑都踩一遍，站在巨人的肩膀上，基于前辈们的经验，能够减少自己走很多弯路。
我的架构设计方法论是积累和实践很多年总结出来的，也是基于以前的各种理论和经验提炼的，不可能完全靠自己摸索出来的。
2018-05-04
Mario
架构设计的目的是什么？
这是个好问题，值得每个架构师和想成为架构师的技术人经常思考。
为了解决软件复杂性，是经典答案；
个人认为架构设计的目的有:
制定群解决业务问题复杂性的解决方案规范，包括核心业务流、扩展点位置、流程重组规范、服务编排方 法、等等，简而言之规范是架构的灵魂，方 法 ‘ 论（比如 DDD）是架构的指导意见，统一技术认知和屏蔽横向业务影响是架构核心价值。
拙见，请大家指正
作者回复：业务复杂度只是其中一种复杂度，并不是每个软件系统都有业务复杂度问题
2018-05-03
小伟
今日笔记：
架构，架者，实体也，构者，行为也。架即数据，构即服务。
架构分业务架构和技术架构，业务架构优先 (决定) 技术架构。脱离业务的技术架构不是好架构，不懂业务的架构师不是好架构师。
技术架构解决业务服务的复杂性问题。
架构可从性能、可用、可靠、安全、维护、扩展、人力、成本、团队经验、推动力等维度切分业务场景的复杂度，按复杂度高低顺序排列，找到解决该纬度复杂性的方案，通盘评估各解决方案间的冲突及可行性，最终得到一个可落地的架构方案。
2019-02-28
码闻强
有时候往往会为了一项牛逼的技术，想着法的引入到架构中去验证，这其实就是拿着锤子找钉子，忽略了技术实际的应用场景。
不同的市场时机，不同的团队素质，也会衍生出不同的架构设计，没有对错，只有合不合适。
作者回复：非常正确，所以架构师的工作是一项头疼的工作，考虑东西很多
2018-05-22
9527
老师您好，
谈谈我学到的
所谓的架构，就是在性能，可靠性，扩展性，安全，成本，之间做出权衡
根据自己产品的需求，在以上几点中选择最关键几个，然后放弃相对不重要的几个
比如创业公司为了成本就只能舍弃其他几个
而银行为了安全就可能需要放弃一些性能
秒杀系统为了性能就要在其他几个中做取舍
不知道我理解的对不对😅😅
作者回复：正确，这个话题后面会涉及
2018-05-04
卡莫拉内西
公司接了一个几十号人使用的政府办公项目，甲方要求上微服务架构。。
作者回复：还是先拿到单吧，这种虽然不合理，但也只能接受
2018-05-04
诗与远方
做为前端工程师来分析项目架构设计时，发现很多设计考量都不在前端，如何突破这个限制让自己成长呢？
作者回复：前端也有自己的复杂度哦，架构设计会分多级，先做整体架构设计，再做前端架构设计
2018-05-04
Mask
老师好，想问下架构师把问题都分析清楚了，怎么体现工作？就是怎么呈现工作成果？是画个架构图，然后配点解释说明文字吗？需要编写代码吗？😄
作者回复：后面有详细的架构设计流程介绍架构师的工作
2018-05-04
softpower2018
分析理解业务痛点，针对痛点进行架构设计！这才是架构的意义所在！多么痛的领悟
2018-05-03
丶 Zero 灬
架构设计不是万能的，而是要合身。深刻了解自身项目，知道身高体重各种围度才能打造合身的架构。而这样的衣服穿起来才舒服。
2018-05-03
老王
是不是没有大数据量（不需要数据库）就不需要架构设计了？比如与嵌入式系统设备通过网络交互的上位机软件，复杂度应该是高可靠性，不能挂。
作者回复：高可靠也是复杂性来源之一
2018-05-03
才才才
首先我们的数据每天以 TB 的级别增长，我想问下我们的数据库应该怎么设计，和选型
作者回复：毫无疑问上大数据全家桶呀，关系型数据库扛不住后面章节会介绍存储这部分
2018-05-03
慎独明强
看到大家的评论我也总结下。订单系统：高性能：RocketMQ8 台多主结构同步刷盘，Redis 集群版 12g 三主分片三从分片，本地缓存，Mysql 读写分离，加分表加 tidb 数据分析加数据归档。一主一从一只读库。主库 16 核 64g (核心功能的查询与写入)，从库 16 核 128g 主要用于对外查询，拉单接口，只读库不用于生产机器用。每天订单量 40w 左右，高峰期每天有是 300w。数据量基本上是订单量 * 7=280w，高峰 2100w。平时一天数据库磁盘新增 1g 左右。服务划分：web3 台，订单发货服务 10 台，拆单服务 10 台，mq 消费服务 5 台，下传订单服务 5 台，定时任务服务 2 台，对外查询接口服务 5 台，配置表服务 3 台，canal 服务 2 台。es 服务 高可用方面集群部署加机器监控，mq 削峰。高性能：redis Mysql 读写分离。订单 Tps 已经被 mq 限流，控制消费线程数，并发 200 左右单机。对于架构这块结合自己业务来说，模块划分为微服务，再中间件把这些起来。这是系统架构设计，还有业务架构设计，对于业务边界划分等等，老师提些建议
作者回复：你的系统架构还比较复杂，从描述来看比较合理，服务拆分没有太细也没有太粗，个人感觉 rocketmq 数量有点多。不到 20 台业务相关的机器，mq 用了 8 台
2020-07-19
吕宗胜 ZJU
非常赞同架构是为了解决系统复杂度这个思路。不同业务架构关注的点也会不一样，比如说对于 C 端业务来说，稳定性是首要保证的，针对稳定性，会衍生出许多不同的架构。同时架构也应该是演进的，业务的不同时期，要解决的复杂性是不同的。
2019-11-02
liyue326
老师 前端架构的话该怎么做呢
作者回复：前端主要复杂度是可扩展，目前基本上依赖框架和前后端分离
2018-07-23
蓝色理想
所有 的软件设计方法 论都可以归 结为降低复杂度 / 囧…
作者回复：说出你的想法，互相交流
2018-05-03
Aaron
架构是为了解决复杂的问题，或者说是解决最重要的问题；目前我正在负责一个金融系统，这个金融系统最重要最复杂的地方就是算法模型，我们在这一块花了很多心思来进行设计。以保证以后他的后续可扩展、算法的时效性等。
2018-05-03
ncicheng
目前云计算、docker 技术流行，各种投标的或规划类项目都得上这个，否则技术方案就不行，没有新意，就拿不到项目。请问李老师，这个怎么破？军工行业～谢谢
作者回复：这…… 还是先拿到项目单吧，毕竟业务第一呀，你把它理解为是架构设计中的合规要求，只能遵守，不能取舍
2018-05-03
piboye
架构设计 一开始都追求性能，后面是高可靠。对于开发人员来说，简单方便高效开发这一块的考虑似乎少了。比如同步模式的协程和异步的选择，rpc 框架和服务发现路由，日志，调用链监控等非功能性需求的非侵入式接入。架构设计首先要能实现业务需求，再就是要方便开发，最后要方便运维。
作者回复：并不是每次都追求高性能的
2020-08-24
piboye
学生管理系统，老师只说了热备这一块，我觉得更关键的是冷备。
作者回复：有热备还要啥冷备？定期备份数据库不算冷备，只是常规的备份
2020-08-24
钱
课前思考及问题
1：架构设计的目的？
根本目的就是钱，和社会主义建设改革开放一样。
其次，比较直接应该是三高三易：
三高 —— 高可用、高性能、高并发
三易 —— 易理解、易维护、易扩展
不过世间哪有十全十美之事，这些如果都想实现那是不可能的，因为有些要求就是相互矛盾彼消此涨的。三高极易增加复杂度，复杂度升高必然难以维护。
课后思考及问题
1：计划一整天学习二十五篇，看来是不可能的啦😄评论太多了，大部分还是优质评论，我感觉评论比正文都耗时间，感觉像买一赠一😀
2：老师的结论 —— 架构设计的主要目的是为了解决软件系统复杂度带来的问题。
这个结论，令人耳目一新直指心扉，那问题来啦！
2-1：软件系统的复杂度有哪些？
我猜是难操作、难维护、样子丑、屁事多、跑的慢，好像一个失去法力的老巫婆。老师觉得哪？
2-2：软件系统的复杂度是怎么产生的？
三高极易带来复杂度，易扩展也极易引入复杂度，当然功能要逻辑复杂也是容易引入复杂度。老师觉得哪？
2-3：假如能够直接降低软件系统的复杂度，那是否就直接减少了相关问题的数量及复杂度？
如果能满足业务需要，我觉得是这样的。老师觉得哪？
2-4：怎么定义或者识别软件系统的复杂度带来的问题？
2-5：识别问题是解决问题的第一步，往往也是极其关键的一步，实际开发中感受更是如此，如果能定位到问题，则离解决问题也就不远了至少走完了一半的路程，那怎么定位问题呢？
我们最近半年都在重构一个维护 N 年的系统，这个系统极其关键，电商核心业务之一，最初的目标是减轻业务人员的运维成本，尤其是大促或节假日时的运维成本。为此业务的运维界面设计的复杂度直线上升，另外追加了一些性能提升的目标，现在项目开发的差不多了，不过由于不允许出现业务问题，需要进行严格的验证，保证实现的业务逻辑不变，其实后台的实现逻辑根据运维界面的调整也做出了调整，导致验证工作极其困难。
我认为提升性能这个目标不应加进去，另外运维界面做出了调整导致后端逻辑调整较大，怎么验证重构前后逻辑能完全匹配的事情，没有在最初想清楚，导致现在验证困难进度缓慢？如果是老师，这个问题该怎么思考才能做的更好呢？
淘宝也应该有这种给飞驰的飞机换轮子的操作吧！怎么保证飞机正常飞行，且换上的新轮子也是合适的？
作者回复：可以用灰度发布验证
2019-08-24
wgg9696
看到老师说自己的第一本书《面向对象葵花宝典》，顿觉熟悉，我电脑中 calibre 中还存储着这本书，时常翻看，没想到又「一不小心」买了您的课，真巧。
我们公司的业务基于 rfid 标签和读写器，我们作为上位机和读写器进行交互，满足业务需求。
高性能：一个上位机会对接 200 台读写器，每个读写器 500ms 会上传 1000byte 的数据，网络层 socket 连接使用 netty 提高性能和可靠性。
按照一个读写器工作 8 小时，持续上传数据，每天一共会上传 10g 数据，这些数据需要存储，便于查询，可以考虑上大数据相关组件。
可扩展：工厂业务扩展性不强，这块可以不考虑。
高可用：这层不太会考虑了（汗颜）
安全性：用户对读写器的配置参数需要做加存储。
作者回复：缘分呐😂😂
2019-06-12
小伟
团队负责的是一个 HCM 的培训模块，核心功能是在导师和学员之间做推荐。业务的复杂度是在推荐算法和查询性能。目前是实时计算，性能是瓶颈，当用户在 500 人时，推荐结果需要数分钟才能展示。其中，加载人员信息的开销和 UI 渲染的开销最大。leader 决定优化加载的信息量，甚至简化算法来降低性能开销，但我觉得是杯水车薪。如果我来做，会从以下入手：
缓存人员信息。因为人员信息的变更频率很低，且推荐计算过程对终端用户透明，可以容忍使用一定程度的旧数据做计算。可考虑 Redis。
缓存推荐结果。因为推荐结果有在多个场景间会被用到，缓存热点结果可降低性能开销。可考虑 Redis，ES。
增加反向代理。因为每次 UI 都要加载头像图片等大量静态数据，可将静态数据单独保存并通过反向代理来降低调用开销。首选 Nginx。
作者回复：思路不错
2019-02-28
李海涛
「架构设计是为了解决软件复杂度」这个原则来衡量，就很容易判断。
作者回复：这个原则可以帮助架构师避免过度设计，或者乱设计
2019-01-16
微风
找到复杂度的过程就是对需求和业务场景的梳理过程。
作者回复：是的，分析出复杂度说在是主要业务经验的
2018-09-28
oscarwin
架构的目标是用最尽可能简单的方法实现复杂的业务，而不是为了本末倒置，想让自己设计的架构无所不能，最后成了超级巨无霸，而实际的业务并不需要。也让我回想起公司业务中，需要给商家后台管理系统添加一个接口，一开始我想用 redis 但是导师说直接用 db 就能搞定，因为管理后台是给运营用的，并没有很高的请求量
作者回复：你的导师不错👍
2018-08-12
走神儿
变化是绝对的，唯一不变的是变化本身，架构设计的目的在于防范后期变化，这本身含有行业经验的内容，也有前人通用经验的总结。像上期所说没有银弹，合适的就是最好的。同样如前所说，变化是一定的，适应变化是架构演进的原动力
作者回复：架构设计的目的不是为了「防范」后期变化，而是要适当预测然后准备
2018-07-19
sherry
生活的每天就像当架构师的每一天，架构要根据业务解决复杂性，生活要根据现实解决复杂度。架构要根据业务的实际需求，人员的技术水平，企业的运营成本做出取舍。生活也要根据自己的目标，能力做出最终的取舍。
作者回复：这算是学了一个技术，顺便领悟了一个道理么😂👍
2018-07-08
阿杜
适合的才是最好的，系统处于不同的时期采用不同的架构，先简单后复杂，不断的迭代，不断的优化架构，选用更重要更适宜的技术，舍弃阻碍系统发展的技术，到了某个时期还要敢于重构，做当下更好的架构。
作者回复：后面的架构设计原则就是讲这部分内容
2018-06-05
Geek_817974
感觉架构就像我们追求买东西的性价比一样，我们只有这么多钱，想买一个既能满足我们的功能需求，又能在其他方面（比如东西比较好看，比较轻便，比较舒适）更好的
作者回复：等有钱了再买更好的，这就是演化原则😂😂
2018-05-20
missa
架构设计在于取舍，权衡。基于当前的业务，也需要考虑到当前的用户量，公司规模大小，发展情况。用合适的架构去解决当前业务的问题。
2018-05-16
星极
1、忌过度设计
2、忌完美主义
3、……
2018-05-11
yoummg
我想问下老师，一个 OTA 公司，公共组承担的业务应该是什么样的？最初我是参考淘宝的 Java 中间件团队，总感觉自己的团队很 low，听老师这堂课受益很大，所有的架构都是依托于业务，大而空的系统设计肯定不可取。
作者回复：中间件团队一般来说是一个公司里面技术水平高的团队
2018-05-10
王旭东
架构设计的主要目的是为了解决软件系统复杂度带来的问题，赞赞赞赞赞赞
2018-05-10
aaaaa
看了文章和评论，我感觉要想搭架构需要很多第三方插件的知识。想问一下，复杂点是不是就是对项目的要求？一般对项目的要求是不是就是性能，扩展，可用，安全以及成本？
比如我目前在弄的是公司的后台，框架是以前就弄好了的，我只是维护。用户除了公司内部人员就只有公司的一些客户，数据来源是日志以及一些线上的服务器，线上大概有几千台服务器，然后主要是有几台充值服。
用的是 mysql，客户主要关心线上服的注册登入和充值情况，而起要求查询必须快点响应，但是充值数据有几千页，而且同时要获取登入注册相关信息，这些信息的数据库也每个表也有几百页，如果响应慢了，客户会重新刷新页面，再次点击，会造成线程不足挂掉，所以上司把这些数据存到了缓存里，就能实现快速查出结果。
由于充值数据数量大，所以在起服是不能一次性把它加载完，就需要将近一个小时，注册和创角也是一样的情况，所以就不能经常关闭维护。
每个客户只能查询与自己平台相关的数据。
这个项目的 web 容器是 tomcat，数据库是
mysql，数据源用定时器从其它服务器获取以及解析日志，感觉没啥东西了。
那我这个项目的复杂点是不是就是性能和可用还有安全性三方面？架构有没有就不清楚了，如果有的话，感觉就是个星型拓扑图
作者回复：几千台服务器已经是很复杂的系统了，主要的复杂度开源我会全部介绍一遍
2018-05-06
野马
所有脱离业务的架构设计都是耍流氓。
2018-05-05
在路上
做架构设计的时候，就是从高可用，高性能，高扩展三个维度，弄清楚项目要求，找到解决方案，还要在不同的方案中间，拿成本来衡量。可以这么理解么？
作者回复：后面会回答这个问题
2018-05-05
王刚
讲的真好～所有东西的出现，都是为了解决问题所诞生～就好比老师讲的架构是为了解决软件的复杂度所诞生～我个人觉得，架构也不是万能的，还的就具体的业务去分析～避免杀鸡用牛刀的举措，反而得不偿失～给老师一个赞👍
2018-05-04
fish007
请教老师，可以以最简单的报表系统为例讲解吗？一张表，比如结核病报告情况，数据来源于各个医院管理系统，然后对该表进行数据分析，发病率、地区分布、趋势预测、报告情况…。结核病分析系统是整个业务管理系统的子系统，其它还有乙肝、布病、慢病…，数据都是从各个医院管理系统通过数据接口采集需要的专病信息。仅考虑设计一个结核病管理系统，之前的想法是：GO 语言做前端 WEB 访问页，用于用户登录、窗口展示、数据报送或采集数据浏览，主要考虑到 GO 简单易上手。数据分析比较复杂，所以申请了 BI@repoort 试用，是报表系统经常使用的分析平台，JAVA 开发，可集成在系统中。然后分别打包在容器里，部署在华为云上。请教老师，这可以算是基于微服务的设计吗？可行吗😊? 如果不可行，能讲解一个可实践的架构方案吗😊? 非常感谢！
作者回复：我理解整个系统的复杂度可能有两种：每个医院管理系统都要对接，报表复杂。
因此你没必要用 go 开发，用 java 足够了，BI@report 如果你们已经用了那就用。
整体来看这不是微服务设计。
2018-05-04
Pantheon
技术为了业务，脱离业务纯粹技术就是浪费
2018-05-04
快乐的小傻子
感悟：不能为了架构，而作架构，架构应能解决产品需求带来的复杂性，更高效的做事情
2018-05-03
三军
哈哈，我们刚好有一个学校的项目还没开发，读到这篇文章很有感觉。
学校情况就是 2 万人左右，教务系统每当抢课必定宕机。
记得有次面试，在这个项目上写了从高并发高性能方面考虑，然而问起什么都不会说😊。
架构设计:
登录方面：基于学校教务系统的代理登录，哈哈，我在想，可以做个缓存系统来避免高峰期的页面缓慢问题。
学生信息方面：就如作者所说，做好储存系统的方案，主机房有主、从备份，还有备机房。
功能方面比较少。
哈哈哈哈
作者回复：看把你乐的，我看的都很开心😃😃
抢课的话，瞬间高并发就是复杂性所在，和 12306 类似，但我理解其实还是你们的系统没做好，因为某个课程抢的人不会是全校都在抢吧？和年级，专业相关，这样算下来，并发也不会高，你认真分析一下，也许真的加个缓存就够了。
2018-05-03
但莫
架构最终是为了知道和阐述系统状态，来满足现有需求和可预期的一部分需求。应该避免假大空，纯凭想象。
在做架构设计的时候应从需求入手，循序渐进，逐步细化。在做架构的过程中要让相关方理解系统设计，可以使用不同的视图工具。比如案例中的物理架构，还可以有逻辑架构和用例图。这样可以让开发人员，客户，管理人员，运维人员，都能很好理解系统设计，方便沟通。
2018-05-03
刘杨
感谢老师的答复，但是对于架构的设计不知如何着手，期待老师后续的讲解非常感谢
作者回复：别急，后面更精彩
2018-05-03
narry
我的感受是：业务复杂会逐渐导致需要一个复杂的系统来应对，一个复杂的系统需要模块的分工，从而导致必须通过架构设计来规划各个模块的功能和相互之间的联系，而架构设计的关键就是要找到具有关键意义的复杂点，让系统能应对复杂业务的需要
2018-05-03
ZYCHD (子玉)
架构设计主要目的是为了解决软件复杂度的，不同的业务系统有不同的需求差异，需要考虑系统复杂度的方面也不一样。道与术的区别，道指导术。
2018-05-03
成功
架构解决软件复杂度，从性能，存储，高可用，安全脱敏方面从技术角度考虑没问题，但商用软件不得不考虑成本和交付这两个维度。
作者回复：复杂度的来源有很多类，后面会详细阐述
2018-05-03
星火燎原
一言点醒梦中人
2018-05-03
刘杨
老师您好，项目在什么时候开始考虑架构的事情。目前我们的产品日活在 6 万左右，我们现在使用的是单体架构。但是有很多子项目，目前团队有 14 个人，因为项目起步设计不好关联性很强，经常会出现修改某点影响其他功能，同时现在产品还没有定型经常会对一些已有功能进行重构
作者回复：你可以思考一下，你们系统现在面临的主要复杂度问题是什么？
从你的描述来看，复杂性主要体现在可扩展性方面，而可扩展性是架构设计的主张复杂性来源之一，因此你们可以开始架构重构。
可扩展性具体怎么做，后面的章节会详细阐述
2018-05-03
18668293795
不禁想起面试的时候问的哪些问题。。。太偏了
2018-05-03
上善若水
架构设计如何解决软件复杂度带来的问题，同时还需要结合现实业务场景及团队状况。正如老师所抛出的观点，需要在高可用、高性能、可扩展性等等其他方面作取舍。所以猜测老师接下来应该是就如何取舍进行阐述
作者回复：猜对了，架构设计原则正在等你阅读������
2020-09-14
escray
架构设计有各种误区，但如果是甲方爸爸要求，那么必须得认真做一份高大上的架构设计，各种新技术、新名词一个也不能少。
在体制内接触过的一些项目，感觉是连需求都没有搞清楚，就盲目的迎合不懂技术的领导和喜好「高大上」的专家。
@代码荣耀 在留言里面说，需求驱动架构，这个说的真好。
另外看到老师在回复中说，一个架构师可以支撑一个 20 人以上的开发团队。那么反过来，如果开发团队人数比较少，那么架构师的存在感应该就不那么强，一般可能由技术 leader 或者项目经理兼任。
有一点好奇，架构师完成了架构设计之后，开发团队按图索骥，这个时候架构师做什么呢？应用还没有发布，也谈不上需求变更和流量增大。
另外，在敏捷团队中，是否架构师的存在感更少？
作者回复：架构师也可以编码，或者架构师支撑多个团队，所以一般小团队小公司不要设置架构师职位，不然就会出现你说的情况
2020-09-01
Geek_cb2227
不管自己的答案是否正确，不进行一定输出，学习的效果是达不到的，无论如何，自己也得动手写写。
团队服务的是电商系统，从业务模块的角度划分，大概分为商品、订单、支付、物流、评价等等模块，整个电商系统随着市场变化，期间做过调整，由最初的分期电商转型为社交电商。
性能：实际上系统的访问量并不大，到目前为止，注册人数大约是 50 万人次，每天的访问量并不大，大约一天能够有 7 千左右的访问量，性能的瓶颈主要在于商品和订单相关操作上，例如搜索、展示、活动等等。为了提升用户体验，提高访问性能，搜索使用了 elasticsearch 组件提升模糊和精确搜索效率，对于首页等等活动页面数据信息，则直接使用 redis 进行数据缓存，避免频繁访问数据库，存储格式采用常用的 JSON。对于电商而言，图片是一个非常重要的资源，公司购买了阿里服务，因此直接使用阿里云 oss 服务。
可扩展性：电商业务变化快，需求不断更新和优化，对于扩展性要求比较高，故而团队进行业务拆分，微服务化，把与商品相关的业务拆分出来，集成于特定商品子系统中，其他系统相互访问调用，由于是内部系统，互相之间访问快。
高可用：由于访问量不是很大，整体业务量并没有上升更高量级，故使用三台机器作为载体，并使用阿里 LSD 进行负载均衡，基本保证了整套系统的高可用
成本：整体业务量还不够大，机器成本相对较低，整个系统机器数量为 6 台。当然，在购买阿里服务的过程中，费用也会随着业务量往上增加
最后，想说的是，对于创业团队而言，阿里服务能够快速提供可靠稳定的服务，还是不错的，并且，能够提供许多功能，让创业团队更加专注于主要业务，保证功能快速上线。
但是，技术人员不能太过于依赖于阿里服务，要不断学习，毕竟一旦业务量大了之后，使用阿里服务的费用就不如自己构建的服务器要节省成本。并且，自主研发这才是一个团队实力提高的良好路径
作者回复：非常好的案例分析������
2020-08-13
王崧霁
架构解决顶层设计问题，作者说得对，去找开发。
2020-08-01
王崧霁
架构是解决当下痛点，架构是不断演进的。
2020-08-01
Jiantao
1 架构是为了应对软件系统复杂度而提出的一个解决方案。
2 架构即 (重要) 决策
3 需求驱动架构，架起分析与设计实现的桥梁
4 架构与开发成本的关系
2020-07-27
慎独明强
架构设计是为了解决系统复杂度带来的问题。
2020-07-19
Yerik
联想到上家公司做的一个公司自用的 crm 系统，用户量不足三百人，也用上了微服务架构，把里面几个模块拆出来单独做成了子系统……
作者回复：哈哈，面向客户设计，面向标书设计一般都是这样
2020-06-18
wesley
架构要符合实际业务场景，不断进化。
2020-06-15
美国的华莱士
用业务的角度来看架构的话，结合自己的经验来看的话:
业务为了快速适应消费者需求，为了赶一波风口产品的架构，这种架构非常简单，简单到别人都已经帮你做好了，你来个二次开发就行了，你甚至简单看一遍数据库表就知道这里面的主要业务结构是什么.
以上，听上去肯定会显得很粗糙，但是很多公司刚开始真的就是这样，因为老板没那么多资金一下子砸进去，没业务支撑的架构再出色在他看来也是画大饼，还不如他自己画，至少自己画不花钱.
作者回复：合适最重要
2020-05-25
程序员小岑
是的，目前在做架构设计时，我会先思考，复杂度在什么地方，在考虑选择什么样的方案，而不是一味追求好的架构
2020-05-14
李乐平
我们目前的 B2B 电商平台架构，采用的微服务架构，针对一些核心服务进行架构设计
订单系统
- 高性能：每天大约 10w 左右订单，由于下单比较集中，一般早上 10
11，下午 24 点，赶上一些促销活动，高峰期 TPS 3000, 单台机器肯定扛不住，按每个服务实例扛 400-500 并发，加上一定冗余，我们部署有 10 个实例，进行负载均衡支撑高并发请求
数据库压力，使用一些调配的 16C32G 的机器 ，主从架构 + 读写分享，对数据库的访问压力性能还可以承受；存放方面，每天 10w 订单，一个月除掉工作日大概有 200w 订单，单表数据量会急剧增加，存储压力是个问题；我们采用分库分表方案缓解单个数据库的存储压力。
- 高可用
订单属于核心服务，必须要保证高可用的，多台实例之间必须要实现故障转移机制，通过微服务器架构的自负载均衡和重试机制实现故障自动转移；加及实例故障及时报警，人为干预定位排查并解决问题
作者回复：挺合理的架构设计
2020-04-16
荣码人生
软件设计的目的主要是解决软件复杂度带来的问题。以下分析这五样和 aws well architect 很像，所以不管基于本地还是云平台，这五方面都是适用的。
目前在做是公司管理系统。
性能：用户是公司内部人员，用户数 2000+，当初设计前后端分离，让后台 api 可以部署到多个服务器，释放后台能力，前端使用 Apache 已经足够应付。
可扩展性：如前面说的，前后端已分离，后端可无限部署
高可用：机器故障，机房故障，分为 web 层，app 层，数据层，app 层是无状态，所以我们使用缓存来存储登陆信息等状态数据，因此 web 层和 app 层只要多台部署即可，而缓存需要更高可用性，然后数据层做读写分离，主从备份
安全性：登陆安全使用各种加密算法，甚至使用第三方校验工具，数据库对敏感信息字段进行加密。整体经营异地机房 AB 备份。
成本：由于是公司核心业务，以上都能较好实现。
谢谢老师让我们在结尾评论，不然光看，不结合自己情况去思考，真的很难把知识掌握。
作者回复：知行合一效果最好
2020-04-05
哼歌儿李
架构设计的主要目的是为了解决软件系统复杂度带来的问题
2020-03-29
谭方敏
公司之前业务服务的用户数以千计，所以我们用单体架构完美地解决了，后来随着用户数以万计了，那么我们正以业务模块化，多点集群的方案来解决，在接下来随着公司业务到达十万级及以上，我们也在打造下一代服务器架构以应对业务增长的需要。
2020-02-27
Jolin
学生管理系统涉及选课，学期初的选修课都会带来一轮高压，设计时候真的不需要考虑性能么？
作者回复：先量化高压到底有多高
2020-02-03
Geek_8c3b7b
老师，我把书看完了，现在发现评论区也是值得学习的地方。专栏和书还有啥区别，我需要听完专栏吗？
作者回复：差不多，专栏评论内容可以让你理解更深
2020-02-02
大山力压 besos
架构的目的就是通过进行分提炼重点然后进行取舍 不知是否可以这样认为
作者回复：先设计可行方案再进行取舍
2020-01-23
CDz
架构基于业务
业务需要取舍（解决矛盾）
从业务场景熟悉分析：
1 高并发会有多高
2 数据是否一条都不能丢
3 线上停止供应大概可以多少时间
4 根本是成本与核心性能的平衡
2020-01-17
Nextep
从事软件开发多年，深感架构即选择，选择即放弃，get 到你要选择的点很重要。
作者回复：赞同
2020-01-08
百里
架构的目的是解决系统带来的复杂性。
提取关键字，解决与复杂。而不是带来新的复杂性。比如秒杀我们要首要解决的问题就是商品超量问题，其次是系统可用性。所以设计秒杀就要对此有的放矢。
2019-12-24
日拱一卒
架构即决策，是在资源、时间、范围和质量之间进行均衡。架构需要考虑各种约束，包括内部约束，例如团队技术栈情况、团队文化，也包含外部约束，例如功能 / 非功能需求、上线时间、领导期望等等。
架构是为了应对软件系统中的复杂度，不同系统的复杂度可能来自不同维度，例如高性能、高可用、可扩展等等，我们需要评估各维度的重要性，然后做出相应的架构决策。
2019-12-21
黄剑
架构设计是为了解决不断变化的业务需求带来的复杂度。如果没有需求随意引入各种高 XX，微服务等等就是耍流氓。
2019-11-22
小菜鸟学 php
我们平台每天有几十万的流量，但是我们平台是 10 年前开发的，没有使用任何框架，里面代码改的乱七八糟，经常 mysql 慢查询。我一直想解决这些问题。
作者回复：重构或者重写
2019-10-30
乄恰似一种蜕变
架构设计的主要目的是为了解决软件复杂度带来的问题
我现在负责都系统都是用微服务拆分都，分成了 10 来个模块，反正现在用没搞清楚这架构为什么要这样做，后面慢慢去了解吧。
1.Web Nginx 服务器集群
业务门户集群
后台管理服务器
定时任务服务器
支付网关服务器集群
短信服务器
7.Redis 集群
8.MySQL 集群
作者回复：除了 nginx，Redis, MySQL 几个集群外，其它都是业务模块集群，可以找老员工了解一下
2019-10-21
lufeng
架构的目的是解决软件系统复杂度带来的问题。这些问题是什么呢？包括高性能、高可用、高可扩展、低成本、安全和规模化。
不同的人在不同的业务场景下，需要的架构都是不一样的。人、场景、架构应该都是定制的、个性的。
让我想了了柔性架构概念，架构需要有刚的一面，核心不变的，也需要有柔的一面，应对变化的。呵呵
作者回复：有点虚
2019-10-20
有米
文中的例子还有一个高并发的问题。例如某个受欢迎的老师，放课的时候，大家都会集中在一起抢他的课！
作者回复：这个不算高并发，每秒几百个对于计算机系统来说不高
2019-10-20
Jackey
一个简单的例子就把问题说明白了，给老师点赞
2019-10-17
小雨 on the way
新公司现在的项目，本来出一个后台接口是一个很简单的事情，但是最初的架构设计为了所谓的规范，用一个接口做了所有接口的事情，通过接口的参数去转发到具体服务，并且还设计了一套很绕的转发规则，从前端传参到数据库的配置数据再到配置文件，经过层层映射，最后才到具体的服务类。这可能就是一个过度设计的例子吧😂。好在我们已经在逐步改造了。
作者回复：架构师升级了么？😂😂
2019-09-28
Sam. 张朝
目前的业务系统，瓶颈在于，所有的主业务相关：订单，会员，都在一个系统中。
并且该系统随着业务的发展，不能满足高可用的要求。
原有系统扩展也不方便，主要复杂点在于订单。
作者回复：先把会员拆出来
2019-09-10
徐风来
学生管理系统数据库选型这块，应该参考峰值，
2019-09-03
fomy
目前框架使用的架构是前一个架构师设计的。有一个消费 MQ 的 task 系统，一个提供 api 和接口的 service。其中 task 负责数据插入和计算的 task 最为重要，不需要频繁更新。而 service 负责数据展现的逻辑。但是我并没有按照他的架构来做，我之前为了方便把 task 的功能移到了 service，造成了一点业务上的改动都要上线解决，影响了数据的插入和更新的模块。所以架构的目的也包含在模块拆分与负责职责之间的一个权衡；还有高可用性上的考虑，保证用户数据没问题的情况下，查询上允许短暂的不可用。
2019-08-09
Geek_5aa3a1
架构设计主要解决当下面临的实际复杂问题，找一种合适的方式去解决此类问题。
很多时候是种逐渐改进的方式，不同阶段使用的框架，技术。可以促进更好的实现方式。需要架构师不断去发现和改进。
2019-08-08
卓不凡
依据系统复杂度来设计架构，说的太棒了
2019-08-07
Geek_88604f
架构复杂度的来源广泛多样，有些是非技术因素导致的，但别小看了它们，其影响可能比技术还深远。
团队：发型的软件需要很多的人员参与，这些人员来自不同的组织，拥有不同的技术背景，不同的组织文化。根据康威定律，组织的架构会影响软件的架构。架构师需要根据组织的结构合理划分子系统。团队的组织越复杂子系统可能就越多，进而导致系统的复杂性上升。另一方面组织的不同技术背景必然会带来不同技术栈之间的协调和互通。适合于甲的互通技术可能不适用于乙，可能不得不因此去开发新的互通技术或者增加转换层。
利益：不同的组织往往代表了不同的利益。软件项目的最终成功不代表团队中各个组织都获得了成功。有的组织本身是项目交付类型的，项目成功了它就成功了；有的组织是技术创新类型的，它的所谓的成功是要在项目中引入新的技术。架构师不得不做出一定的妥协，在某些自系统上引入新技术，而新技术本身具有一定的复杂性，坑有多深是未知的，甚至到最后才发现是天坑，但为时已晚。不得不上各种临时规避措施导致架构耦合。
质量：即使有了很好的软件架构，糟糕的交付也可能让原本可以成功的软件项目失败。因此质量保证应该是架构师必须考虑的一个关键问题。为此不仅仅要求做好代码审查，还要引入一些标准，工作实践，原则或工具。特别是不同技术栈的子系统如何做 CI 浩大复杂的工作。
作者回复：这些复杂度主要影响工作量，不会影响架构设计方案，相反，成熟的架构师应该避免此类因素影响架构设计
2019-08-03
许凯
上，止，正
2019-07-26
萧润曦
我做架构设计的原则是 不追求高性能目的 以稳定以及可伸缩性为目的… 做好领域模型的设计 而领域模型设计是方便以后独立拆分…… 高内聚低耦合 是我一直坚守的设计思想
作者回复：合适原则👍
2019-07-23
刘佳旭
真不错，学到了很多，或许是我太菜了…. 哈哈😄
2019-06-17
建强
我公司目前在开发一套社区矫正人员管理系统，这套系统面向全省社区矫正人员，信息量较大，且监管人员每天要检查矫正人员的行踪和去向，系统每隔半小时从移动、电信公司那里获取矫正人员的位置信息，以便于监管人员每天进行监管。我从以下几方面来分析这套系统的架构：
高可用：由于监管人员需要实时监管矫正人员，必须保证业务不能有中断，因此系统要做负载均衡以及容灾、后备等措施；
高并发：由于每隔半小时获取全省矫正人员的位置信息，全省矫正人员约有 3 万多人，获取数据时的并发量较大，数据处理经常出现瓶颈，因此也是需要负载均衡；
大数据：全省矫正人员 3 万多人，每隔半小时存贮一次位置信息，位置信息包括经、纬度坐标以及地名信息，一个矫正人员一天就要存贮 48 条记录，全省 3 万矫正人员每天大约要存 150 万记录，日记月累，普通数据库可能支撑不了，因此可考虑采用分布式数据库进行存贮，将数据分散存贮，或采用一些非关系型数据库，如 HBASE、MongDB 等进行存贮。
以上是我一点比较粗浅的分析，请老师指正。
作者回复: 1. 高可用是最关键的特性
高性能的分析不太对，这个数据量级的性能压力很小，你要按照 TPS 来计算，即每秒处理的数据量
数据存储部分其实数据量不大，你计算一下按照 G 的单位去评估，同时也可以考虑讲历史数据归档
2019-06-15
__fulin
架构设计的真正目的
架构设计的主要目的的是为了 ** 解决软件系统复杂度带来的问题 **。
架构设计应该注意的点：
1）从实际项目需求着手，分析系统复杂性并针对复杂点进行设计。
2）架构设计应有针对性，避免盲目求大求全。
简单系统的架构设计应从那些方面分析：
1）性能：web 服务器，数据库，缓存。
2）可扩展性：应根据系统的实际需求进行考虑。
3）高可用：负载均衡（异地多活），存储高可用（机器故障 - 设计 MySQL 同机房主备方案、机房故障 - 设计 MySQL 跨机房同步方案）。
4）安全性：信息隐私、金融相关。
5）成本：服务器成本、人力成本、维护成本
案例：大学的学生管理系统
性能：采用 Nginx，MySQL 数据库，无需缓存。
可扩展性：系统功能稳定，可扩展空间小。
高可用：无需负载均衡，需考虑数据库存储高可用。
安全性：学生信息有一定隐私性，只需做三点：Nginx 提供 ACL 控制、用户账号密码管理、数据库访问权限控制。
成本：系统业务简单，成本较低。
2019-06-11
SoberChina
说实话现在做的系统各种耦合，下游服务不可用都会暴露给用户服务，用户服务根本不 care 这些东西。我理解的架构肯定要求有技术，技术肯定要有有规范，一个项目没有一定的规范，再加一个没有不求上进的 team ，产生屎一样的项目是有原因的。
阅读心得：架构设计要求合理避免过度设计。
2019-06-05
北极的大企鹅
感觉学生系统还是要考虑下负载和数据缓存，因为现在的学生管理系统包含的还有学生的成绩，而每年期末结束后，很多人早早回家了，所以他们会通过外网，App 等方式查询成绩，还有的学生系统绑定了课程。选课，抢课的需求也是有的。
作者回复：一般不需要，一个学校才多少人，现在的服务器处理能力很强的
2019-05-21
金蝉子
架构设计的主要目的是为了解决软件系统复杂度带来的问题，
1、通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计
2、架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性的解决问题
3、理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案
作者回复：理解到位
2019-05-20
我瑟瑟的方法
画图是用的什么软件
作者回复: LibreOffice Draw
2019-05-08
whhbbq
想到之前做的一个项目，是对接影院的系统。要求线上预约平台要稳定，跟影院系统对接要稳定。一旦出问题可能导致，消费者在预约平台购买成功了，也付款了，但是在影院那边显示没有这个订单。
我理解此系统的复杂度在于，1、要对接很多影院的系统，每个影院的系统可能都不一样，修复了一个 bug 或者加了新特性，需要逐个升级。整个后期维护成本很大。2、稳定性要求高，但是存在很多不稳定因素，如影院软件升级、网络异常、程序 bug 等。
作者回复：分析不错
2019-05-05
Illiya
架构设计学习心得：
目的：将复杂的简单化：
原则：适合的才是最好的，最好的不一定适合
注意：过犹不及，利弊权衡，生搬硬套，削足适履，得不偿失！
2019-04-19
鸡蛋🎱 达芬奇
架构设计一定分析出系统设计得关键复杂度，老师得很好！不同行业不同系统，同一行业不同系统，相同行业同样的系统的复杂度都要依据公司的具体业务情况而定。
2019-04-17
凌
架构设计是为了解决软件复杂度，如果本来不复杂，又硬上解决方案，只会徒劳无功
脱离业务实际情况谈架构都是耍流氓，为什么要演进，因为系统都是从小到大，一味地追求高可用、高并发、高可拓展，最终造成过度设计与实现，架构本身是为了解决软件的复杂度而诞生的，如果因为架构设计导致软件的设计更加复杂，那就会适得其反
架构是一种决策，是在一个有约束的盒子里去寻找最优的解，这些约束有：团队经验、成本、资源、进度、业务所处阶段
需求驱动架构：在需求分析阶段，需要有架构人员「跳出代码，总揽全局」，构建业务和 IT 的桥梁
举个例子，我们用《学生信息管理系统》来做一下架构分析
功能分析：登录、注册、成绩管理、班级管理
高性能：使用频次低，性能不作为主要的考虑要点
可靠性：数据是不能丢的，成绩数据很重要，所以数据库这边是复杂点。数据库可能遇到机器故障所以要做同机房的主备方案，可也能遇到机房故障所以要做跨机房同步方案
拓展性：上线后功能趋于稳定，新增功能少，也不做为主要的考虑要点
可用性：宕机 2 小时，停机维护等等，对使用者的影响都不大
安全：没有很多隐私的数据，简单做即可
成本：两台服务器就够
2019-04-15
俊杰
「也不包含强隐私（例如玉照、情感）」这里的玉照想必本来是 yan 照 但由于敏感词被迫改的吧
作者回复：你懂的
2019-04-11
客舟听雨来 coding
不同的业务有不同的要求，复杂度也会随之不同。架构师要高度站在业务发展的前头，深入思考业务布局以及主要矛盾，分析出系统的主要复杂度是什么，从而可以设计出良好的系统架构。还有，好的架构是跟随业务发展一步步迭代出来的。
2019-04-10
小小杨
架构设计也可以说是设计的目的是为了解决软件复杂性带来的问题，所以识别复杂度是架构设计的基础。我做的项目比较偏技术，复杂度主要体现在性能和可用性，因为涉及到并发和分布式集群。现在这方面的知识比较缺乏，设计起来比较的吃力。
作者回复：多看多学，要靠积累
2019-03-27
周敏 - 18956083558
你好李老师，我们的系统涉及到大量的图像识别，所以性能是主要的瓶颈，这类业务场景设计架构时你能帮着提供些指导意见吗
作者回复：图像识别算是计算高性能，要么优化算法，要么加机器
2019-03-14
Geek_fb3db2
指望架构解决所有问题不可能 我们需要有的放矢
2019-03-09
行者
分析下我们项目：
为客户端提供接口，用户使用特点是节日 QPS 会显著上升，每天每个时段都会有用户访问。
对应在架构设计中，着重考量了系统扩展性 (docker)，系统高性能 (压测发现问题接口，提升 QPS)，数据库 (mysql) 主备。
2019-02-27
davidyan
既然架构设计的目的是解决软件系统的复杂度问题；领域建模称为软件核心复杂性应对之道，那是不是领域建模是面向对象之后的解决方法？另外，看目录好像没有涉及到面向对象和领域建模，能分别说说它们的适用场景嘛？
作者回复：可扩展里面有，我没有用领域建模这样高大上的词，而是用「拆分」来应对业务复杂性，因为领域建模可能把系统拆的很细。
领域建模是一种面向对象设计的具体方法，通过领域建模识别出领域对象
2019-02-15
付志波
目前的业务系统复杂在需要集成各种 api 接口很零散，有些模块之间存在业务关联。内部有多个自动化流程一旦其中一个模块变动会影响其中的自动化流程，也就是存在分布式事物问题
2019-01-23
发条橙子 。
老师 ，小白一名 ，上面提到的 web 服务器用 nginx 。但是下面的架构图 最顶上是 nginx ，下面是 web 服务器我理解这个应该是 Tomcat 的应用服务器 。所以最上面的 nginx 主要的作用是什么呢 ？？只是文章说的 ACL 的作用么
作者回复：是的，nginx 做 ACL，https 证书卸载这些事情
2019-01-03
cxyfreedom
看完第一篇文章之后，就去看了 4+1 视图方法。然后看完第二篇和第三篇正文和留言后，感觉 4+1 视图方法很好的说明了如何进行最初的架构设计方法。
作者回复: 4+1 视图告诉我们如何描述架构，但架构本身如何设计的，4+1 视图不能告诉我们，先有架构设计后有架构设计图
2018-12-29
惜心（伟祺）
架构设计的主要目的是为了解决软件系统复杂度带来的问题
2018-12-27
杰之 7
通过这一讲的阅读学习，明白了设计软件架构的目的，是为了解决系统的复杂度。不是为了所谓的多个高 XX。因为有的高并不能对我们实际的业务产生多大的帮助。
在下半节中，老师通过一个大学的学生管理系统的案例解释说明了设计的思路。在各项指标中，性能，和稳定性，高可用，安全性和成本方面，高可用需要设计 Mysql 同机房主备方案，跨机房同步方案，对于大学生人均每天一次的访问，其他指标都能得到满足。
所以，通过这节的学习，设计软件架构不是目的，目的是为了解决实际业务的复杂，我们需要思考如何能满足实际需求而设计合理的软件系统，这时我们需要学习和实践的。
2018-12-19
silence
架构就是从缤纷复杂的需求中找出真实的重点和需求中的痛点，以痛点和重点为切入点，着手解决系统的整体规划，把力量用在刀刃上！用哲学的话说就是，抓住主要矛盾，解决主要矛盾！
作者回复：你的高度更高😀
2018-12-15
dream
看了几篇，怎么觉得留言区比专栏作者还牛逼，描述的更通俗，更易理解
作者回复：留言区卧虎藏龙😀
2018-12-14
harryshayne
架构设计我觉得和项目管理也有很多相似的地方。架构设计的目的是在一定上下文条件下进行最优或者次优的设计来解决当前或适当超前所带来的问题，项目管理也是在一定的资源条件下，包括人，财，物，时间，环境等使得项目能较好地满足业主，用户，老板，员工各自的需求。架构设计其实还和政策的制定类似，好的政策也是在一定条件下做出满足大部分人需求方案，否则就是烂政策，所以架构设计的哲学是通用的决策类型哲学，不知理解对否
作者回复: 《原则》一书中提到：进化是最伟大的力量，是永恒的
2018-12-02
李健
『没有银弹，只有权衡』，根据大佬所说，架构的目的不是追求极致的银弹，而是去权衡解决自己的系统存在的问题。
自己的软件有一个现阶段的增长极限，与用户量。是不是我们初始架构的时刻，有一个自己的客观评判。1、对系统进行架构的时候根据初始评判去架构，争取达到现阶段的最优目标，也可以说最复杂几个业务的最优目标。
2、对于现有的问题，则是统筹现有需求，精力，财力去做最适合的架构，可以重构可以增加。
收获
1、架构不是所有的都怼到一起，用最新的技术干活，而是用最适合的技术给公司的需求做统筹搭配。
2、前期架构需要重点盘算自己的主业务复杂度，尽量为后期迭代留下整改的空间，减少架构成本。
3、架构前期技术选型，建议我们这种小白，考虑到传统技术和流行技术的统筹。可以考虑多重方案、技术，然后同技术对比，最后一一筛选，即增加了知识储备，又认真负责了统筹
作者回复：很到位👍
2018-11-27
sgl
学生系统的复杂度在于某一时刻的峰值请求，比如抢课的时候
作者回复：一个学校抢课的人数不会超过每秒 1 万吧，每秒 1 万要不算高，但也不是一台机器就能抗住的
2018-11-13
贾洵
架构从两个方面帮忙软件落地实现。一是基于业务需求出发，切忌照搬抄袭。架构是一款软件的骨架，设计是一定要从实际出发。有时候不设计也是一种设计。二是落地实现。设计视图中逻辑视图确认子系统边界，运行视图描述业务场景，既子系统内部交互。这时再引入架构设计，对其中高可用，高性能等点进行设计；物理视图考虑部署时高可用；包括数据库和中间件
2018-11-11
贾洵
借用公司技术大牛的一句话：设计既分类，等待即浪费
2018-11-11
贾洵
还是从需求出发，了解业务场景。根据业务场景整理出合理可落地的架构设计。但是只要充分了解需求，是否可以满足设计过度的问题呢？
作者回复：你永远都不可能「充分」了解所有需求😄
2018-11-11
Columbia
印象中架构都是懂 java 的程序猿在干，
但是我是 C++ 程序猿，有木有毕业学习架构呢
作者回复：架构和开发语言无关，同样的架构，C++, PHP 都可以来做开发
2018-11-04
Dylan
想到之前的一个项目，公司刚起步准备推出一款图片社交应用，什么架构完全没时间去考虑一个所谓完美的方案，大家就是想着先上再说，后台就是简单的 2 台 mongodb，kafka 做消息队列，redis 做缓存～直到 A 轮之后才去慢慢完善整个的架构，毕竟用户访问大了，要确保不宕机，app 体验流畅～～现在想想当时真的是随意～～
作者回复：方向对了，方法不对，创业开始不要大而全的架构，但也不是不要架构设计
2018-10-11
wenjianping
架构设计的目的：
识别和解决项目中主要的技术问题，保证项目能够顺利实行
保证的可以预见的未来不会存在无法处理的技术问题
架构设计的任务
- 发现主要的设计点
性能、搞可用、可扩展性、安全、质量、系统目标等
发现主要的技术问题：团队不熟悉的技术、解决方案
围绕主要设计点，提供对应的解决方案和支持
技术上的方案
管理、流程上的方案
2018-10-11
lucoffee
我还没有架构师方面的经历。
2018-10-10
lucoffee
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
2018-10-10
微风
迭代本身就是一种降低复杂度非常好的方法，配合架构的演进，即使出了问题也是一个单点突破的问题吧
作者回复：迭代本身不能降低复杂度，但可以快速验证系统是否真的解决了复杂度问题
2018-09-28
self-discipline
每次看留言都会有很多收获啊，把自己当成作者去看这些问题就会更有意思的
作者回复：我也可以从问题中学习😊
2018-09-21
self-discipline
如果公司有厉害的人，我个人认为开始做微服务比较好，虽然有技术成本在内，这要比把垂直项目彼此为微服务要好的多，对业务的发展快速迭代都有好处的，前提是不差钱的公司，有厉害的人
作者回复：有这个前提还说啥啊，不要微服务，一个大系统都可以😄
2018-09-21
self-discipline
选择微服务架构的原因是方便开发，因为当初和现在的人员技术能力层次不齐，我想要烂了代码就烂掉一块，方便每个人处理自己的代码，从而不影响我的心情。其次业务增加启动太慢的，闹心，很多问题的处理要求修改后就要上线，垂直项目重启后网站接口就垮掉了，灾难性的后果，微服务后单独模块重启速度快，10 秒左右不影响使用。讲之前垂直项目微服务化，找到约束项目可拓展的环节，就是支付回调环节的，优先进行微服务化，达到后期拓展方便。架构和面向对象，结构化编程都是解决一时问题的，其实工作中同样是引入个技术或者项目会给你解决现有问题，引入新问题的，只要机会成本小就值得引入
2018-09-21
成功
高性能，高可用，可扩展，安全性，成本，代码规范
2018-09-12
张汉桂 - 东莞
大师你好，对于案例最后的图我有些感兴趣。请问数据备份要用两台备机吗，这个要怎么做啊？我做开发好几年了，都不知道像这种主备机的架构怎么做。我所在的公司，数据备份都是冷备，这个脚本建个定时任务，每天凌晨生成一个全量备份文件。
作者回复：用数据库本身的同步复制功能就可以😄
2018-09-08
YoungerChina
架构的目的，解决系统的复杂性和健壮性，提供的稳定性，可靠性，持续可用的服务，请大师指点
作者回复：你的这个是大而全的，并不是每个架构都要求可靠性，持续可用
2018-09-06
二少爷
架构设计的主要目的是解决软件系统复杂度带来的问题
2018-08-30
kimi
架构就像找媳妇，不能要求太多，合适就行
作者回复：媳妇要求太多怎么办😂😂😂？
2018-08-15
文竹
目前涉及到的产品用户数量小于 10，所以无需考虑高性能。公司对可用性有严格的要求，自己规定的可用性为 99.99%，所以技术高可用和存储高可用都需要考虑。由于目前产品业务非常简单且用户数量少，并没有发现有需要考虑可扩展性。产品分为客户系统和管理系统，客户系统的安全性必须要考虑，管理系统的安全性可通过网络等手段解决。由于只需 3 台机器就可以部署好整个产品，对于公司来说人力是不缺的，所以成本可以无需考虑。
其实之前，我在设计产品的过程中并没有考虑复杂性，而是一未模仿。也只考虑了计算高可用和系统安全性，并没有考虑存储高可用，系统安全性方面后台和前台设计技术手段一样，并没有区别对待。
作者回复：学以致用，知行合一，这样效果最好😊
2018-08-14
李雷
1、软件、经济好像很多领域发展壮大的同时都会伴随着结构问题
2、分析问题的方法：分治
3、软件架构目的：降低分析软件领域发展同时带来的结构问题的难度
2018-08-12
桌小洛
架构设计是解决系统的复杂性，这里还有一个很重要的点：提前解决。
若果没有架构设计，等到开发中期，或者上线之后才发现复杂性带来的问题，如性能，安全等问题。那么就需要重构整个系统了，可以说非常痛苦。
所以说为什么需要有架构设计：因为架构设计可以提前解决系统复杂性所带来的问题
而提前解决这些问题，避免这些问题在后期出现正是架构设计的目的所在
作者回复：提前要注意一个提前度，后面架构设计原则会讲到
2018-08-09
vicwang
架构设计的主要目的是为了解决软件系统复杂度带来的问题。切勿贪大求全，把脉问题，对症下药。
2018-07-24
日拱一卒
我从这篇文章中学到的整理如下：
架构设计不能过度设计，高大全的架构不能要。
软件架构是用来解决「软件复杂度」的，脱离了业务需求去做架构设计往往会失败。
架构师对业务需求的洞察能力非常重要，不能仅仅从技术角度来看待项目。
作者回复：很到位👍👍
2018-07-21
日拱一卒
我从这篇文章中学到的整理如下：
架构设计不能过度设计，高大全的架构不能要。
软件架构是用来解决「软件复杂度」的，脱离了业务需求去做架构设计往往会失败。
架构师对业务需求的洞察能力非常重要，不能仅仅从技术角度来看待项目。
2018-07-21
蔡
架构设计目的，解决复杂度
2018-07-15
钢
复杂度的分析是从 性能，高扩展性，高可用，成本，安全性这些方面考虑，是否还有其它方面
作者回复：这些是常见的，不同业务有自己独特的复杂性
2018-06-24
Cola
数据与业务服务实现了分离，是多进程服务集群，但是一些公用服务如权限，服务治理，推送等服务耦合度还比较高。下一步其实就是去中心化，公有服务模块化，引入消息队列与 redis，提高服务器可用性和伸缩性，总的来说我们公司的架构演化挺符合架构进化史的，在小型的时候达到快速上线的要求，然后慢慢地往一个好的方向演进。
作者回复：这样挺好😄
2018-06-14
空无
请问像一些小项目，只是内部的一个 xx 管理系统而已，这样还需要架构设计吗？
作者回复：本篇的学生管理系统就是小项目，只要是真正线上运行的系统都需要架构设计
2018-06-14
蓓岑 2015
软件架构不是一蹴而就的，也不是万年不变的，而是在软件运行的过程中不断演化、演进的。
2018-06-05
千年孤独
架构既决策。
明确需求→分析复杂度→做出决策
嗯，感谢留言区第一的朋友，有启发。
2018-06-04
陈英锋
架构设计往往需要很长时间的思考和磨合，然而现在很多面试官喜欢拿他们生产上的业务来询问相关架构设计，要求在短短时间内给出一个大而全的架构
作者回复：这种面试方式不好，短时间理解对方的业务比较难，我一般会举微信淘宝等例子，因为业务大家都懂
2018-06-02
火山飘雪
「架构设计的主要目的是为了解决软件系统复杂度带来的问题」，最好的不一定是合适的，合适的才是最好的。我的理解就是，架构设计要贴个自身系统的业务复杂度去进行设计。
2018-05-30
tiger
这让我想起我面试时候一直讲不好的一个项目，就是因为没把项目的复杂度讲清楚，希望能从中有所收获
2018-05-28
唐朝首都
识别复杂点，预测复杂度，找出解决复杂点的合理方案。
2018-05-28
小小鸟
为啥看留言时间 要比看内容时间还要多 哈哈 真好
作者回复：极客邦跟我说留言质量很高，读者都是卧虎藏龙，你可要保证你的文章高质量😂😂😂
2018-05-25
LEO
如果把「架构设计的主要目的是为了解决软件复杂度带来的问题」改为
「架构设计的主要目的是为了解决软件使用过程中因对象、目标、流程、环境复杂度带来的问题」
会不会更容易去理解架构设计的目的和本质，以及架构设计的目的和意义？
作者回复：太长了记不住😂😂
2018-05-25
易燃易爆炸
老师写的这篇文章，让我重新认识了当年的学生成绩管理系统。感谢～
作者回复：麻雀虽小五脏俱全😃😃
2018-05-21
许鑫
银弹制服了凶残的怪兽，但是未必所有的怪兽都怕银弹。软件开发是个不断演进的过程，各个阶段痛点不一致，因而想一招鲜吃遍天不大可能
2018-05-20
何 yuan
架构师需要从项目的进度，成本，范围，质量，风险，人资等多个维度去分析合适项目的架构，只关注质量，忽略其他维度肯定会对项目造成灾难。架构要想体现价值必须结合实际场景。脱离业务而追求高大上的架构是浮夸的画蛇添足式的。谨记架构的核心要务「取舍」
2018-05-20
熊能
华仔老师么么哒
2018-05-19
tangbl93
老师，现在我们的代码 (iOS) 整个逻辑一团糟，现在的主要复杂度应该就是在保证业务稳定的前提下搭建一个基本的架构体系了吧😂
作者回复：那就是可扩展性有问题，先设计一个基本架构
2018-05-19
重剑
为了架构而架构，好像再说我😅
作者回复：这就是你的心得体会和收获，知道自己做的不对也是收获😃
2018-05-18
Forrest Li
架构设计的目的是什么？为了解决软件系统复杂度带来的问题。
要知其然，也要知其所以然，诱惑与选择太多，这样把握住原则，才不至于迷失
2018-05-18
纯洁的憎恶
我第一时间的感受是，做架构为了长远打算，要可扩展、易维护。现在我明白了自己的想法是在要求面面俱到，而且会带来主次矛盾都没解决、落地遥遥无期等灾难性的后果。根据软件工程发展的历史可以清晰了解到，架构设计的核心目的是应对软件系统高复杂度带来的问题。换句话说就是把复杂的事情简单化。先找到复杂点（主要矛盾），然后有针对性的解决问题，是架构设计的核心逻辑。
2018-05-16
周偲
牛逼的架构，就是解决了当前的问题，以及考虑了未来一段时间的需求变动之类的。想要一劳永逸，就是扯淡
2018-05-14
吴建中
接触过几个公司在客户现场做的系统，当用户提出优化时，我会跟他们说问题出在架构上，架构太老，跟不上业务发展，之前架构有明显缺陷。这是架构师应该有的视野，角度。
2018-05-13
孙振超
寻找答案从定义问题开始，关于为什么要进行架构设计这个问题其实没有去思考过，只是一个惯性动作，在真正设计时也是更多的关注功能性需求，同时对系统的容量、耗时要求会有更多的关注，而我当前所负责的系统在某些场景下对数据的准确性和实时性有很高的要求，也是因为对这一块关注的缺失导致了两次故障的发生，才不得不对此投入精力去改造。
作者回复：有的放矢才能设计好架构
2018-05-13
Vincent ly
老师好，我公司 (某大型保险公司) 正在做私有云平台。
关于这个云平台架构，结合您的分享，我的一些思考如下，不知是否到点
1 私有云平台承载的的应用主要为功能测试，因此数据可靠性和可用性要求 均不是特别高。不需要考虑异灾备等复杂场景
2 云主机申请并发相对比较多，消息队列集群要求较高
3 测试主机对流量要求较高，不能依赖于原生的 open vswitch，需要引进三方 sdn 设备
作者回复：功能测试对可靠性和性能确实要求不高，云主机申请并发和流量需要给出具体的性能数值才能做判断。
另外，通常情况下私有云的复杂度在于云主机的管理，功能和逻辑很多，可扩展是关键复杂度，需要做好服务化
2018-05-13
高阳路人
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
2018-05-09
aslong 龙
架构是系统的顶层设计，目的是为了解决系统的复杂度。那么，这个系统的复杂度如何判断呢，是不是就跟具体的业务和架构师的认知水平有关系了？
作者回复：后面章节讲述了常见复杂度的来源
2018-05-09
solan
说到架构，在国内还有一点得考虑，那就是：客户或老板。有时候要适当考虑他们的规划和性格，业务方向，团队规模和实力，投入成本，市场预期（扩张时机），业务团队能力等等，这些都会影响到一个产品的系统架构。
作者回复：架构设计原则会讲
2018-05-09
小思绪
随着时间的推移，用户量上涨，软件系统的复杂度也会变更，我的意思是主要矛盾也会转移，那之前的架构可能就没法满足现在的需求，是不是意味着架构也需要变更呢？整个系统架构变更是要花很大精力的。
作者回复：软件架构设计原则会回答这个问题
2018-05-09
100kg
架构固然重要，但是也不能过度设计，简洁高效的架构能加速项目的开发进度，过度设计的繁重的架构会严重拖慢进度
作者回复：架构设计原则会解释
2018-05-09
乘风
复杂度，1. 因业务需求，某条业务线的访问量大，拆分单个服务或集群，2. 需调用 sdk 进行用户资产操作，数据双向保证，任何与第三方数据交互的操作都进行记录，3. 数据库使用主备
2018-05-09
有渔 @蔡
看了留言，发现爱学习的往往是技术业务强的人。架构跟个人的成功一样，没法复制。是个人成长路上适合环境生存，最后你凤凰涅槃，成功了。这时你的思维，格局，做事方式等就是个人的架构。另外，明朝朱元璋设计的制度就是经过不断的历史血泪教训后，适合当时环境的架构。
作者回复：视野宽广，知识丰富
2018-05-09
走小調的凡世林
架构设计的主要目的是为了解决软件系统复杂度带来的问题。那么业务复杂度也可以通过架构解决吗？比如我们部门内部管理系统有好几套，内容管理系统、报表分析系统等，运营人员使用的话要登录两次，为了降低业务复杂度，引入单点登录功能，业内是否有比较好的集成框架推荐？
作者回复：可扩展章节有讲述
2018-05-08
blue
架构设计的主要目的是为了解决软件复杂度带来的问题，由此可以引申出问题「什么系统在什么情况下的什么复杂问题」
在实际的工作中，最忌讳的是一口想吃成大胖子
我理解的架构师更多的是学会思考与沟通，在成本中进行决策，任何技术脱离了业务场景都是没有意义的，就像纸上谈兵一样，所以架构师是产品与技术的桥梁，不会为了几辆车建高速公路，也不会只给几万辆车搭独木桥
作者回复：架构设计原则部分会讲到
2018-05-08
孙晓明
李老师，您好：
一、对于「软件设计的主要目的是为了解决软件系统复杂度带来的问题」的理解：第一步，架构设计需根据需求确定系统各点的复杂度；第二步，根据复杂度的高低排列优先级，依次进行架构设计，不求面面俱到，但必须解决核心问题。
二、问题：
关于如何分析软件系统的复杂度，是否有可以参考和学习的方法论？能否深入介绍一下？
2018-05-08
黑暗浪子
其实你还是有点啰嗦，整篇文章意思就是架构设计的目的是降低复杂度。但是你可能忘记了，架构的可扩展性，我可不希望多了一个新需求，我这套架构就无法扩展了。也就是说我认为架构即未来
2018-05-08
伟伟
系统设计的目的是为了解决业务问题。架构设计的目的其实是为了分离复杂度。
复杂度分为业务复杂度和技术复杂度。业务复杂度分离可以通过领域驱动等等去解决，而技术复杂度可以从高性能、高可用和数据一致性三个维度去分析。
2018-05-08
大利猫
架构的第一步：准确定义问题
作者回复：非常正确
2018-05-07
金桔
就目前我们的系统设计，在这个指导思想下去分析思考，确实走进了误区。这一课感触颇深👍
作者回复：说出你的故事
2018-05-07
itperson
如何针对不同技术性能指标设计恰当的架构这是一个很有趣的问题 希望您给予指点
作者回复：后面会有高性能设计篇章
2018-05-06
stanley
运维出身再转开发，对架构理解和设计未必停留在应用的堆叠和设计一定要结合当下考虑长远但不能太长远，技术一定要服务于人的理念。目前所在公司属于回流员工，原来的架构师已经离职，但发生了一件让所有人瞠目结舌的事情是，原来架构师设计的劝架架构（或框架）大家都认为很好很符合当下甚至未来，但架构师离职后才发现，不进是新进员工还是老员工都无法掌握原来架构师这套架构，一个现有功能的维护都需要 review 该模块所以代码，最尴尬的是架构师写得代码身为 5 年 + 的开发竟然看不懂。。。而我们使用的需要是全宇宙最牛逼的 php。。。请大神解惑
作者回复：架构本身太复杂也是问题所在
2018-05-06
YMF_WX1981
如果一个需求：能利用用户碎片化时间、能应付弱网环境和多样的网络协议、适应业务逻辑高度复杂和多变、运行于多种互联网 web 平台的电商应用。
隐私性没得说肯定需要，而且能开放用户配置。
容灾？的话，互联的多地存储，增一台，数据同步，宕一台，数据能从附近最近机器访问。
能对产生数据自动分类，目的是永久数据放 redis，临时数据是产生用完即扔，这方面用户也可配置，提供数据查询下载..
多少人在线，自动开启多少服务器，多少带宽
… 我想这种应用主要是 hold 住互联网 web 应用，符合人用网规律和机器利用规律
2018-05-06
舟舟
菜鸟一枚，架构的目的就是提前分析出项目上可能出现坑，针对这些坑提前预留好扩展点，在适当的时候去填上这些坑。而技术人员最容易犯的错误就是用一些时髦高大上的技术来显示本事
2018-05-06
赵龙
老师，我们公司目前给各家医院的某个科室做系统，每家医院除了公共需求外都存在一些个性化的需求，目前我们是开了很多分支，每家医院针对一个版本分支进行开发。新合作一家医院确定需求后找一个相似的版本分支再开出一个版本分支进行开发，能从架构设计上弄成一个产品级的系统吗？？？通过不同配置给各家医院进行使用，如果这样做，前期整体规划会花大量时间吧
2018-05-05
Dylan
架构设计的主要考量是复杂度，复杂度的度量也是一门艺术活
2018-05-05
任鹏斌
我们目前项目架构存在严重的设计过度问题。
不贴近用户需求，70% 以上的功能是用户平时不会用的，或根本不需要的
人为增加项目复杂度，流程设计繁琐，为所谓的可扩展设置很多预留功能，实际用户新增需求是这些预留功能根本无法满足，反倒是因为本身设计太复杂，随便一个小的改动可能产生不可预估故障。
系统使用太复杂，有的系统设置连开发人员都弄不清楚怎么用过段时间就忘记，更不用说普通用户。
服务器资源浪费，平均内存和 cpu 利用率不到 30%
其他不一而足，但无力改变
作者回复：关于可扩展性，后面会有多个章节涉及
2018-05-05
小叶子
在学校学生选课系统的框架中，nginx 和 web 服务器分离为两层，不太理解。nginx 不就是各种服务器的实现手段吗？web 服务器也可以用 nginx 实现。这里是想说负载均衡服务器吗？
作者回复: nginx 做反向代理，可以实现 acl 等功能，如果你的 web 服务器有这些功能，确实不要 nginx 也可以
2018-05-05
燃点丶
我正在设计一个日志分析系统。看完后找到系统的复杂度在哪。以及架构方向。
2018-05-05
rubin
满足当前业务并可预见性可扩展的架构就是好架构，不一定非得高并发，高性能，高 xx，好的架构一定是满足当前业务需求，达到省时，省钱，省心，老板和用户开心了就好。下期是不是讲讲如何设计架构，如何迭代架构呢？多谢了！
作者回复：别急，复杂度还没讲完呢😂
2018-05-05
大光头
架构设计一般是为了满足新业务需求和复杂度，然后选用哪种框架则在需求，复杂度和小组技术栈进行权衡，最终的架构都是这些约束条件下的妥协或者说最佳解。
2018-05-05
MichaelJY
业务架构，的确是。任何不以业务为基础而想象设计的架构都是耍流氓！
架构是慢慢演进的，前期业务量小集中式能够完全满足，等业务量稍大了就要想着服务拆分，业务量再大点就得想着动态扩容，保证数据一致性等…
不过任何时候在设计架构时都要考虑扩展性，否则推倒重来就会很痛苦
2018-05-04
Even
深入浅出，又有真实案例，赞，一直只是个 TL，第一次这么系统的学习架构知识，期待后面更精彩
2018-05-04
上善若水
架构的目的是把各个组件按照一定规则组合成一个系统。这个系统的价值要远远大于内部各个组件之和。
2018-05-04
李绍文
预则立，不预则废，预者，架构设计也。
2018-05-04
清泉
软件架构就是为了让软件系统能够满足业务的要求。
2018-05-04
超级码利
卧槽，被击中了，能明白这个指导思想太关键了，听完这期都感觉已经值回票价😃，后面 50 期都是白送。
2018-05-04
DullBird
第一次分析自己所接触的系统，总觉得很不到位，但还是想把思考的写下来才会有提升。
我们公司的系统主要是采集数据的业务，由一个单体的控制服务端包括页面呈现端，和采集机集群多个节点组成。
主要业务是采集各种各样的数据。流程是服务端配置和调度控制，分派任务到采集端，采集端采集完数据
性能：对采集时间要求不是特别高，不同的采集项，要求的采集的时间不同。配置采集一天一次，一次大概采集 1W 台设备，预计 2 小时完成。
拨测数据 5 分钟一次，一次也采集大概 1W 台设备，5 分钟内必须完成。并发任务多的时候可能 2W-3W 个任务同时下发。为了提高性能，程序内部的
配置信息（设备信息，采集指标信息，调度信息）采用了缓存，并通过采集机集群和轮询分发，并发去执行任务。并把数据流和控制流分开，采集控制信息通过
服务端和采集机的长连接传递，采集数据通过 activityMQ 上报给服务端入库。
可扩展：扩展性是我们系统的关键问题，因为是采集业务。需要采集的内容随业务变化，采集的方式也各不相同。现有架构处理这个问题，
是通过在采集机上实现不同的采集能力，并且将需要采集的内容封装成独立的任务，单台采集机机集成所有的采集能力，分派到不同的任务，就执行不同的
采集方式。其余的配置和调度，轮训下发，数据上报，采集数据结构采用的统一的规范，实现不同的采集，从配置 -> 调度 -> 到下发 -> 采集 -> 入库的动作都是一样的。
可靠性：配置的设备信息，指标数据不可丢失，结果数据按数据不同，最短不需要保留，最长保留 3 个月。用的 oracle 数据库，仅需要做主备或者定期备份。
由于告警数据需要采集，程序宕机接受时间在 30 分钟内，可以使用看门狗进行进程监控。
现在的问题：
- 控制服务端为了提高效率，配置信息使用了缓存，做双机热备的时候，备机的缓存与主机的不一致问题。
考虑是否将缓存单独提取成一个服务。
- 原先的设计是不同的采集项，都封装成不同的任务，相互独立，实现采集机的集群使用
比如采集 A,B,C 三个指标，就生成 A,B,C 三个任务，不论发给哪台采集机，都会去执行采集。
随着业务更加复杂，有些采集任务互相之间存在复杂的逻辑，比如采集 C，一定要 A 采集完之后，
并且 A 的采集结果是 X 的时候，采集 B，B 的结果为空的时候采集 C。
2018-05-03
巧锋
为了解决软件系统复杂度带来的问题
2018-05-03
键盘猴
项目也是逐步发展的，使用的架构也是随着时间推移慢慢演变，做项目经常碰到的两个问题，一个是过度设计，想的太多；另一个是没有为未来设计，考虑的太少。
现在手头上这个项目就是属于第二种问题，需求迭代也快，动一发而牵全身，不可能一次调整整体架构，只能随着迭代每次重构一小个模块。实践越多，越对于「与复杂度做斗争」有感触。
着眼整个项目实现过程，觉得编码其实重点不是编码，而是思考的过程，如何分配资源，如何做取舍，代码也只是反应了思考的结果和文法功底
2018-05-03
小土
架构是为业务和人服务的，注意业务在前面。架构在满足业务的同时，给开发人员带来便捷才是好，都是一个权衡的过程。
2018-05-03
c@ini@o
看来和企业架构设计关心的不一样
作者回复：别急，学完专栏你就知道都涵盖了
2018-05-03
jacy
架构设计的主要目的是为了解决软件系统复杂度带来的问题，一语道破
2018-05-03
CrazyTrain
也可能有这种想法，虽然可以解决当时的问题复杂度，但后续发展呢，所以作为架构师应该为长远考虑。所以各种设计又加进来了，又带来了一系列复杂度，所以这种观点哪里有改进的地方？就是架构一定要着眼于未来，不仅是当下。
作者回复：后面会有章节阐述你的问题
2018-05-03
Steven⁰⁰⁸
目前在一家创业公司，架构方面也负责，但是之前没有这方面得经验，属于硬上的，第一版架构参考了创始人上家公司的架构，刚开始听起来不错的架构，随着后期的深入开发，越来越觉得有弊端，如 web 请求通过 activemq 进行消息分发，这样做事可以做到横向扩展，但是面临同步转异步的问题，同时中间加了 activemq 这个环节，每次请求时间会相应增加 目前在第一版的基础上改进，把不好的去掉，但还是不知道现在的设计 希望向楼主多学习
作者回复：学完专栏课程，你就可以尝试回去撸起袖子就重构，有问题咱们到时候结合业务案例交流。
2018-05-03
加油
看完本文，发现公司架构师的架构设计就是 java 流行框架堆砌，业务都不熟悉，感觉架构被玩坏了，老师，该如何避免越陷越深
作者回复: java 流行框架是为了快速开发，但并不是每个软件系统的复杂度都是开发效率，因此框架不要滥用
2018-05-03
才才才
老师，我们公司现在存储遇到了一些问题可以帮忙指导下么
作者回复：你直接写你的案例，我看看
2018-05-03