不想当将军的士兵不是好士兵，努力学习成为架构师吧

曾经终败给现在 2023-02-26 16:19 22阅读 0赞

### 不想当将军的士兵不是好士兵，努力学习成为架构师吧 ###

*  一、什么是架构？
 *   *  1.1 什么是架构？
     *  1.2 什么是生命周期
     *  1.3 为什么会产生架构
     *  1.4 什么是核心生命周期
     *  1.5 什么是业务
     *  1.5 什么是技术
     *  1.6 软件的核心是什么
     *  1.7 软件架构师的职责是什么
     *  1.8 技术、业务与架构的联系
 *  二、成本与收益
 *  三、架构目标需要适应业务的发展
 *  四、从价值出发－找寻学习与工作的新思路
 *  五、架构设计与架构思维
 *   *  5.1 好的架构师有什么特点
     *  5.2 什么是架构思维
     *  5.3 什么是架构设计
     *  5.4 为什需要架构设计
     *  5.5 如何做好架构设计

CSDN：Leo.yuan：[比代码更难的事！看完这些思维习惯的人，都成为了架构师][Link 1]  
博客园：雪山飞猪：

*  [架构技术及架构要素][Link 2]
 *  [什么是架构？][Link 3]
 *  [架构设计与架构思维][Link 4]

# 一、什么是架构？ #

架构技术：  
\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TnY7c4Gb-1594869089249)(https://img2018.cnblogs.com/blog/662544/201901/662544-20190115164816351-202911215.png)\]

架构要素：  
![format_png][]

软件架构就是将人员、技术等资源组织起来以解决业务问题，支撑业务增长的一种活动。可能比较抽象，可以从架构师的一些具体工作任务来理解 这句话含义：

**组织业务**：架构师通过探索和研究业务领域的知识，构建自身看待业务的”世界 观”。他会基于这种认识拆分业务生命周期，确立业务边界，构建出了一套解决特定 业务问题的领域模型，并且确认模型之间、领域之间的关系与协作方式，完成了对业 务领域内的要素的组织工作。

**组织技术**：为了能在计算机世界中运作人类社会的业务模型，架构师需要选用计 算机世界中合适的框架、中间件、编程语言、网络协议等技术工具依据之前设计方 案组织起来形成一套软件系统方案，在我看来软件系统就像是一种技术组织，即技术组件、技术手段依据某种逻辑被组织起来了，这些技术工具被确定了职责，有了明确分工，并以实现业务功能为目标集合在了一起。

比如 RPC 框架或消息队列被用 于内部系统之间的通信服务就如同信使一般，而数据库则负责记录结果，它更像是 一名书记员。

**组织人员**：为了能够实现利用软件系统解决业务问题的目标，架构师还需要关注 软件系统的构建过程，他以实现软件系统为号召，从公司组织中聚集一批软件工程 师，并将这些人员按不同工种、不同职责、不同系统进行组织，确定这些人员之间的 协作方式，并关注这个组织系统是否运作良好比如沟通是否顺畅、产出是否达到要 求、能否按时间完成等。

**组织全局，对外输出**：架构师的首要目标是解决业务问题，推动业务增长。所以 他非常关心软件的运行状况。因为只有在软件系统运行起来后，才能对外提供服务， 才能在用户访问的过程中，解决业务问题。架构师需要关注运行过程中产生的数据比 如业务成功率，系统运行资源占用数据、用户反馈信息、业务增长情况等，这些信息 将会帮助架构师制定下一步架构目标和方向。

所以软件架构不仅仅只是选用什么框架、选用什么技术组件这么简单。它贯穿了 对人的组织、对技术的组织、对业务的组织，并将这三种组织以解决业务问题这一目 标有机的结合在了一起。

很多面试的候选人在被问及他所开发的系统采用什么架构的问题时，只会罗列出一些技术组件、技术框架等技术要素，这样看来其根本没有理清架构的深层含义。

也有一些架构师只专注对底层技术的研究，以为打造一个卓越的系统是非常牛逼的事 情，可是他忽略了软件系统的价值是以解决业务问题的能力、支撑业务增长的能力为 衡量标准，所以最后生产出了很多对组织，对业务没有帮助的系统。

## 1.1 什么是架构？ ##

生活中总是看到充斥着各种架构词汇，如下图：  
\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8WVS0cu1-1594869089253)(https://img2018.cnblogs.com/blog/662544/201908/662544-20190829100645930-710995132.png)\]

架构的本质是以拆分生命周期的方式来做增长。

## 1.2 什么是生命周期 ##

生命周期：事物的生老病死  
人每一天的活动，眨一次眼、吃一口饭，都是一个生命周期，生命周期又包含生命周期，每个生命周期都有一个主体  
以<用户购买>生命周期为例，可以拆分成

1.  <物品选购>（物品意向）
2.  <物品执行购买>（购买行为）  
    拆分出来的物品选购可以外包，例如导购、网上购物、智能推荐

## 1.3 为什么会产生架构 ##

人最终都会消逝，而人总想活得更久、占有更多、享受更多，如何才能延长自己的生命？  
同样的时间创造出更多的产出，相当于把自己的生命延长了。

于是有了所谓的时间管理，为了让每份时间更高效，又出现了精力管理。

古代，一个人必须要先种田，完成粮食的产生，并消费粮食，结束粮食的生命周期才能完成能量的获取以维持生命，而粮食的生命周期外包出去后，人类的核心生命周期并没有受到影响，却大大的节省了时间，延长了自己的生命。正是因为有了分工，才形成了人类社会

## 1.4 什么是核心生命周期 ##

核心生命周期：必须由自己完成的事  
围绕核心生命周期切分，非核心的生命周期独产出来，并行地开展工作，设立沟通机制，使非核心围绕核心做出贡献。

被切分的生命周期，如果连续的时间内持续执行，就不能切分出去，例如：比如孕妇十月怀胎，不能切分成十个人一个月完成  
稻盛和夫就是一位牛逼的架构师，提出阿米巴经营。

## 1.5 什么是业务 ##

解决人类问题，支撑人类自身生命周期，使人类获得利益

## 1.5 什么是技术 ##

通过人为创造条件，让指定的规律按照人类的意愿发生

## 1.6 软件的核心是什么 ##

软件的核心：模拟人类的业务  
软件最早更多的是应用在科学计算，对于大部分行业而言门槛比较高，建立在数学、物理、电子电路等学科  
传统企业业务增长方式：增加人和空间，成本很高，而虚拟空间的增长成本远低于真实空间，拆分生命周期开始转到了虚拟空间。  
以语言类似，很多人学习英语等语言，最终从事语言本身研究的人少之又少，软件主要还是服务于其他行业的，所以我们需要涉猎各行各业的知识，科学、教育、经济、历史、艺术、心理等等。  
不变的规律：让非核心生命周期的处理更少地占用人类的时间，变相的延长人类生命

## 1.7 软件架构师的职责是什么 ##

1.  理解业务组织架构，对业务生命周期拆分
2.  根据业务生命周期对软件开发生命周期进行拆分
3.  结合两者匹配合适的组织架构

简单地说：架构师拆分生命周期，技术人员实现生命周期

## 1.8 技术、业务与架构的联系 ##

1.  业务是核心，技术是解决业务问题的工具，架构是让业务长大的方法
2.  架构用技术来实现拆分，而技术需要架构来合理组织以提升效率
3.  技术为解决业务问题而产生，没有了业务技术也没有存在的前提

# 二、成本与收益 #

正如之前所说软件系统只有在运行的时候才能创造价值，也就是说软件系统能否 7\*24 小时＊ 365 天稳定的工作关系到公司的收益水平。所以开发团队对生产环境的 发布总是小心翼翼，对解决生产环境的问题总是加班加点。

而软件系统的成本则体现 在软件构建过程，这时候我们就能理解那些工程技术如项目管理、敏捷开发、 单元测试、持续集成、持续构建，版本管理等的价值了，他们有的是保证软件系统正确性， 有的是为了降低沟通成本，有的是为了提升开发效率等但总的来说就是为了降低软件 的构建成本。所以在提升系统服务能力，创造更多业务收益的同时，降低构建成本也是一种提升收益的有效手段。

作为一名软件工程师而言，我们往往处在软件构建过程体系中的某个环节，我们 可以基于成本与收益的关系去思考自己每一项技能的价值，学习新的有价值的技能， 甚至在工作中基于成本与收益的考量选择合适的技术。比如在逻辑不大发生变化的地 方，没有必要去做过多的设计，应用各种花俏的设计模式等浪费时间。这样我们才能 成为技术的主人。

# 三、架构目标需要适应业务的发展 #

架构的目标就是为了支撑业务增长，就是提升软件系统的服务能力。可是话虽说 如此，但真实却要做很多取舍。比如对初创团队而言，其产品是否解决业务问题这一 设想还没得到确认，就立即去构造一个高性能、高可用的分布式系统，这样的架构目标远超出业务发展的需求，最后的结果就是浪费大量人力物力，却得不到任何起色。

架构师需要审时度势，仔细衡量正确性、大规模、可用性三者的关系，比如今年业务 蓬勃发展日均订单 300 万，基于对未来的可能预测，明年可能有 3000 万的订单，那 么架构师应该要着重考虑大规模和可用性。而且每一点提升的程度，也需要架构师衡 量把握，比如可用性要达到 2 个 9 还是 3 个 9。

回顾自己以往的工作很多时候就是因为没有确立架构目标导致浪费了组织很多资 源，比如在之前的创业团队中，由于本人有一定的代码洁癖，经常会花费很多时间和 同事计较代码质量，这样本可以更快上线的功能却需要被延迟，当时过度追求正确性 的行为是与创业团队快速验证想法的业务需求不匹配的。

# 四、从价值出发－找寻学习与工作的新思路 #

向前一步，为更大的价值负责：不要因为自己是开发人员就不去关注软件运维， 不要因为只是测试就不关注软件开发，因为你关注的越多你越能看清全局的价值目标。如果只关注一亩三分地，那么注定这辈子只能困守在这一亩三分地里，成为一名流水线上焦虑至死的码农。

试着转变思维，从架构师的角度思考价值问题，看看能否 将技术贯穿到业务、到用户、到最终的价值去。之前我的朋友说过要把产品经理踢到 运营位置去，把程序员踢到产品经理位置去，这样才是正确做事方式。这句话也是类 似的意思，向前一步才能懂得怎么做的更好。

像架构师一样思考，用价值找寻重心：人的迷茫是因为找不到重心，而价值的意 义在于引导我们思考做哪些事情才能实现价值，先做哪些事情会比后做哪些事情更能 创造收益。像架构师那样全局性思考，把遇到问题进行拆分，把学习到的事物串联起来，努力构成完整的价值链条。

# 五、架构设计与架构思维 #

## 5.1 好的架构师有什么特点 ##

1.  技术好。至少代码容易读，容易扩展，重用性好，这不仅需要学习面向对象和设计模式，还要通过大量的编码实践，不单单是停在纸上谈兵的阶段
2.  懂得业务。不了解业务，就不能设计出贴合业务的架构，而行业的相关知识也不是短时间能积累起来的。
3.  良好的沟通能力。架构师需要沟通确认需求，需要让团队理解架构设计。
4.  有架构思维。懂得用抽象、分治、复用、 迭代等思维降低软件复杂性

## 5.2 什么是架构思维 ##

降低软件复杂性，有几种有效的方式：抽象、分治、复用和迭代，架构思维就是这几个的集合

1.  抽象思维  
    架构是为了满足业务需求而存在，需要通常是一些文字性的描述、原型、UI设计图，这些最终都会变成代码让机器执行。  
    我们必须先进行抽象，把需求变成计算机能识别的模型。  
    例如，抽象出各个用户、订单、内容等模型，划清各个角色的责任以及对象交互的方式，隐藏很多无关紧要的细节。
2.  分治思维  
    对复杂的系统分而治之，分解为小的、简单的部分。  
    例如针对高并发场景，可以通过设计将流量分到不同的服务器，避免单台服务器过载。  
    又例如，将一个1000行的函数，封装为N个独立的不超过50行的函数的调用
3.  复用思维  
    复用是提升开发效率的最简单有效的方法，通过对相同内容的抽象，让其能复用于不同的场景。  
    很多新手程序喜欢复制粘贴代码，如果需求变化，需要修改所有粘贴过的地方，开发效率低且难以维护，同时还浪费很多测试的精力。
4.  迭代思维  
    好的架构都是演进过来，很少有架构是一步到位，我们需要保证不影响业务正常进度的基础上，逐步迭代成最终合理的架构

## 5.3 什么是架构设计 ##

架构设计就是用最小的人力成本满足需求开发和需求变更，用最小的运行成本来保障软件的运行。  
常用的方法例如：

1.  使用微服务架构，把复杂系统拆分成一系列小的服务，再拆成功能模块，让人员更好地分工协作
2.  前后端分离，让程序员专注某个知识领域，降低开发难度
3.  分层设计，隔离业务逻辑，减少需求变更带来的影响

## 5.4 为什需要架构设计 ##

1.  需求让技术变复杂。做一个博客和做一个谷歌，技术复杂度不是一个等级
2.  人员让技术复杂。软件开发通过是一个团队，成员水平不一样，擅长的技术方向也不一样，如何有效地协作是一个很大的考验。
3.  技术本身复杂。软件项目使用的编程语言、框架、组件、数据库、人工智能、大数据等技术，都有学习成本
4.  要让软件稳定运行也复杂。软件开发完成上线后，充满了各种不确定性，比如云服务商可能宕机，比如明星发个微博可能造成系统瘫痪，又比如有人删库跑路了

正因为存在以上这几个原因，我们需要架构设计去降低这些复杂性

1.  降低开发成本。复杂系统拆分成多个相对简单的服务，使得普通程序员都可以完成，降低了人力成本。
2.  帮助组织人员高效协作。通过抽象和拆分，让开发人员可以独立完成功能模块。
3.  组织好各种技术。选择合适的编程语言、协议、框架、组件等，最高效地实现需求目标
4.  保障服务稳定运行。利用成熟的架构方案，例如负载均衡、限流、降级、熔断等，保障服务的高可用。

## 5.5 如何做好架构设计 ##

架构设计要做好，需要大量的经验积累，不过我们可以站在巨人的肩膀上，基于成熟的架构设计方案  
改造，变成适合自己业务需求的架构

1.  分析需求。对产品的需求进行抽象，分析用例，了解各种用户角色和其使用的场景
2.  选择相似的成熟架构设计方案。例如微服务架构、前后端分离，还要根据团队选择合适的开发语言和框架。
3.  自顶向下层层细化。好的实践是自顶向下的，不过早陷入技术细节中，从整体到局部规划，设计好部署架构、分层和分模块、API设计、数据库设计等。
4.  验证和优化架构设计方案。完整的架构设计方案，需要有多次的评审，充分收集各方面的反馈，反复修改后确定，另外，还要考虑架构预期能满足多长时间的业务增长，比如半年还是一年还是三年。

架构设计需要有高屋建瓴的眼光，不仅要有架构思想，还要有不同场景的架构实践，更要学习前人实践经验的总结。架构设计是更像是一种内功，需要自我不断地修炼，以便应对各种场景下的挑战。

[Link 1]: https://blog.csdn.net/yuanziok/article/details/106137021
[Link 2]: https://www.cnblogs.com/chenqionghe/p/10272924.html
[Link 3]: https://www.cnblogs.com/chenqionghe/p/11338451.html
[Link 4]: https://www.cnblogs.com/chenqionghe/p/12549664.html
[format_png]: /images/20230209/40e7c35ef5df4e44b806344b38b124c6.png