03 | 架构设计的目的

架构是为了应对软件系统复杂度而提出的一个解决方案。个人感悟是:架构即(重要)决策，是在一个有约束的盒子里去求解或接近最合适的解。这个有约束的盒子是团队经验、成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体(人，财，物，时间，事情等)。架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。 需求驱动架构。在分析设计阶段，需要考虑一定的人力与时间去"跳出代码，总揽全局"，为业务和IT技术之间搭建一座"桥梁"。 架构设计处于软件研制的前期，一方面，越是前期，如有问题，就能够越早发现，修改的代价也就越低；另外一方面，也意味着，软件实施后期若有架构上的修改，也需要付出更多的代价。 今日得到: 1 架构是为了应对软件系统复杂度而提出的一个解决方案。 2 架构即(重要)决策 3 需求驱动架构，架起分析与设计实现的桥梁 4 架构与开发成本的关系

今天读完文章，思考了下我们系统的复杂点，我们系统是一个承上启下的系统，根本没自己的表，所有数据都是调第三方接口取，然后汇总聚合给前端浏览器，突然明白最近老大为什么要搞es去异步聚合第三方数据了，这样以往我们需要调第三方多次接口取的数据，以后调自己es查询一次就可以了，这样性能更高，且逻辑更简单，更容易维护，以往优化这种性能问题的方式，就是多线程，然而多线程也是要消耗资源调，而且代码反而更难以理解，原来最好的优化方式不是把串行变并行，而是把串行干的多个事的数量去减少，首先要根据系统复杂点想到合适的解决方案，其次才是用什么优秀的框架叫代码更牛逼一点，否则一开始就算错的

我觉得做软件架构是为两件事服务的：业务架构和业务量级，这应该算是“软件系统复杂度带来问题”的具体化吧。 业务架构和业务量级都是从每个具体项目的实际应用场景中提炼出来的。 业务架构是对业务需求的提炼和抽象，开发软件必须要满足业务需求，否则就是空中楼阁。软件系统业务上的复杂度问题，可以从业务架构的角度切分工作交界面来解决。设计软件架构，首先是要保证能和业务架构对的上，这也是从业务逻辑转向代码逻辑的过程，所以软件架构的设计为开发指明了方向。另外架构设计也为接下来的开发工作分工奠定了基础。 业务量级表现在存储能力、吞吐能力和容错能力等，主要是软件运维期业务的复杂度。做软件架构设计，是要保证软件有能力托起它在业务量级上的要求的，如果软件到运行使用期废了，前面所有的工作都付诸东流了。不同的业务量级，对应的软件的架构复杂度是不同的，所以对于不同的项目，业务量级不同，架构设计也不同。 做业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必须先设计软件架构，试图不经分析直接套用先前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重来，更不要说直接拿别人的现成架构方案了。 所以每个软件在开发前，都要结合自己的应用场景设计适合自身的软件架构，现成的架构方案只能借鉴，不能直接套用。 另外，由于业务架构和业务量级也会不断调整或长大，软件架构也不是一劳永逸的，会随业务不断调整。

这篇内容完全符合我们公司目前现状，为了架构而架构。原本3个人负责的nodejs系统现在改用JAVA开发，光架构师招了快7，8个。不到2000人使用的系统没有一天不出点小故障，开发过程更是痛苦，三天两头的开发环境跑不起来。说是微服务，不过是把原来单体结构按功能拆分，按层级拆分，本来就拆分的够多了，为了开发要启动很多服务。每个新来的架构师都要引入一套自己的架构，结果可想而知

架构就是。当你想拉屎的时候首先得去找厕所。选择一个什么样的厕所。 1.距离选择。如果太远可能就漏出来了 2.成本选择。如果拉屎太贵也不合适 3.性能选择。好的厕所可以拉的心情舒畅

伟大导师马克思说过：主要矛盾处于支配地位，次要矛盾。。。也会有影响，架构设计就是提前预判可能遇到的矛盾，用最小的代价解决它

老师好，我们目前在做内部的对象存储中控台，满足的需求有以下几个: 1.方便内部非开发人员做数据存储 2.提供对象存储的图形化界面 3.监控整个存储集群的存储相关的指标，例如存储量，下行流量、api调用等等 这几个需求也算是我结合公司的现有业务状况，以及对象存储的特性，自己总结的。 系统上线以后，我预计的使用情况如下: 1.大的天使客户都是一些职能的业务部门，由存储集群提供底层的存储接口，通过中控台进行监控，图形化操作 2.其他零散人员，可存储一些工作上的数据 目前我只是做了个demo出来，整体架构:nginx做前端的负载，springboot提供服务，mysql存储元数据，redis做消息队列，以及缓存，数据通过接口传到存储集群 这个架构也没做太多考虑，就像老师您说的情况一样，只不过公司其他的系统也差不多都这样。 对象存储中控台的业务复杂度我思考有以下几个: 1.提供高可用，高性能的上传下载功能 2.提供bucket 以及对象的查询功能 3.提供低延迟的监控统计功能 4.并发访问量个人感觉都集中在存储集群的接口调用，中控台这边并不高，但是一定要做到系统的高可用，保证内部职工正常的工作使用，同时mysql也要做到主备和异地多活，以及redis的主备 老师这样的分析可以么，针对这样的业务，现有的架构有问题么

1. 问答引导式由浅入深来讲解很赞 2. 一个简单的例子能说明相关问题也很赞，就是这样，大家有时不需要大而全的大公司大例子，反手一个赞，加油，运华兄

我不是架构师，但是有一颗这样的梦想。小时不识月的时候，以为架构就是ssm，就是几种中间件的堆砌，简单粗暴，我上我也行的心态，后来接触的越多，业务复杂了，又开始忧来其如何了，为什么要这么设计，为什么用这个，接触概念也越来越高大上，开始如作者所说的大牛都该展现自己的技术，就是要上高性能高并发等等，就是要往复杂了去设计，盲目的去崇拜复杂的设计，而恰恰忽略了设计的本质是为了解决一定范围内的问题也就是软件复杂度，其实没必要那么疯狂，也没那么简单。适合的才是最完美的，脱离不了业务，也离不开现实，譬如成本控制，进度控制等等。所以我应该静下心来，认真的去学习那些优良的设计的背后，如何在选择上驾轻就熟，如何在这个规则里游刃有余……

架构是解决复杂度的问题。那么复杂度有很多不同的来源，比如人（不同的代码风格，不同的编程习惯），比如业务，比如技术。那么架构不可能面面俱到的解决所有问题，必须要分析出所面对的一个或几个关键的问题，这样架构的设计就能有落脚点，而且问题解决也不会有大的冲突。 架构设计在发展的不同阶段面临不同的问题，例如我们公司刚开始就做了业务拆分，后端是多个服务，前端一个站点，并且提供了一个服务互相调用的公共代理，现在主站越来越庞大，涵盖的业务越来越多，所以要做业务拆分，公共代理所包含的服务也越来越多，也要进行拆分。另外一个业务要调用多个服务，如何去监控调用链的完整性，这也需要解决。 所以架构本身在不同阶段集中解决几个最主要的问题，之后随着业务，技术，问题的不断变化，架构的重点也在不断调整。