软件架构，程序员如何提升架构思维?（上）

思维脑图

什么是软件架构？

软件架构就是通过对软件生命周期的拆分，在符合业务架构的前提下，达到软件本身访问增长目的的方式。

说到软件架构，很多人会认为软件架构就是一堆框架的组合，其实不对，软件架构本身是对于软件实体组织形式的阐述，使用框架的意义是快速完成软件架构设计，而不是取代软件架构设计，两者本质上是不一样的，它们的关系更像是设计图纸和所使用的原材料的关系。

软件架构离不开软件开发团队的组织架构，这个组织架构是软件开发生命周期和软件运行生命周期的执行者。离开了组织架构，任何软件架构设计都是纸上谈兵，因为架构的核心生命周期就是架构的执行。

由于软件架构离不开组织架构，那么软件的开发工作在软件公司就形成了工作分工。软件开发工作的分工是经过长期发展而形成的，分工之后形成了不同的工作角色，有人负责收集汇总需求，有人负责编写代码，有人负责执行测试，有人负责上线部署等。

什么是组织架构？

软件架构若把软件看成虚拟的人，那软件架构实际上就是虚拟人的组织架构。架构拆分的原则，首先来源于业务自身的组织架构，软件架构要保持和业务组织架构的匹配关系。其实也只有软件架构和组织架构保持匹配，软件架构设计才能真正落地，软件架构师才能真正拥有工作的成就感、归属感。其次来源于软件开发团队自身的组织架构，没有组织架构的软件团队是不存在的，即便是现在流行的扁平化组织架构管理体系，组织架构依然是存在的，只是层级被压缩到较少程度而已。最后来源于用户的流量对软件本身的冲击，这其实是软件模拟人类行为的一种方式，一个人使用和成千上万人同时使用的业务场景都属于正常情况。如果软件开发团队的组织架构和业务的组织架构能一直保持高度一致，内部损耗就会达到最小，软件的架构会更简单，软件架构有效落地的可能性也会大幅度增加，软件模拟人的行为也会更加真实。

软件架构师岗位

我们需要有人能够回答下面这些问题。

• 我们这个系统的边界是什么？

• 我们系统由哪几部分组成？

• 各模块之间怎么通信？

• 选择什么样的基础技术？

• 为什么要这样选择？

• 技术方案未来会遭遇哪些坑？

• 我们的备选方案有哪些？

• 从技术角度这个应用将来如何持续扩展功能？

我们开发一套复杂的软件系统需要进行前期规划，对于研发流程来说这个叫总体设计。做任何事情都需要规划，一个复杂的软件更需要规划，如果没有一个良好的设计规划会使后面的维护扩展变得非常艰难。

很多公司设了软件架构师的职位，主要职责是做出架构设计，他们具备一定的影响力，但并不具备调动组织架构的权利。这样的职位往往不能发挥架构师的作用，有时候还会起反作用。软件架构师必须是一个组织的领导人，有权利调整这个组织的架构，才能够更好地发挥架构师的作用，才能够把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。

那么，在企业中谁才是真正的架构师？

一个好的技术领导者就是架构师。

一个开发团队的领导，如果不能在架构方面给出意见，那就不能在整个设计环节给出自己的观点或者对团队进行指导，也就可能会在整个软件开发流程中脱节，进而丢失自己的技术领导力，也就做不成技术管理者。

一名优秀的技术管理者，技术在前，管理在后，并不是说两者有太大的轻重差异，而是你需要花费70%的时间在技术上，只能花30%的时间在管理上，但是你需要用这30%的时间做完100%的管理工作。

当然，也有另一种方式来允许架构师角色独立存在。架构师可以由专门的个人或者团队组成（目前大部分的软件公司的架构师角色都是这样形式），他们承担新技术、框架的调研工作，负责对用户提出的需求进行评估，采用新的技术做出产品原型、输出技术调研报告，供产品部门在技术选型和技术架构选型时参考，这也可以体现架构师的水平和贡献。

架构师的责任是要把软件生命周期和业务生命周期放在第一位。

软件生命周期的核心在于软件运行生命周期，以及对软件运行生命周期的拆分和组织。业务生命周期的核心在于对业务的拆分和组织。

对于软件的生命周期还要考虑软件的开发生命周期，在开发架构上要思考软件架构要如何设计才能支持业务流量的增长。在代码上，要对业务代码和访问代码做好架构拆分，要确保业务代码符合业务的生命周期，使得业务生命周期活动的结果积累在生命周期的主体上，也就是要具有内聚性，避免散落到访问代码中。

在团队达到一定规模之后，架构师大部分时间需要花费在思考上，也可以继续编程，但是编程的目的是验证架构是否合理，所以不要受是否需要编程这一思维的束缚。如果设计得不好，那么团队就会走很多弯路，如果想要设计得很好，你必须自己或者带领团队做很多的测试、预研工作。

软件架构的思路

要做好软件架构，首先是要学会拆分生命周期（软件生命周期和业务生命周期），并且有能力去指导企业形成相应的组织架构来落实软件架构的实施。软件架构是服务于业务的，因此架构师无法去直接调整业务利益的，只能够在某种程度上去影响。

架构师的目的是为了应对增长，而要达到增长，所以架构师应该把需要增长的业务了解清楚，挖掘出核心生命周期，并确定核心生命周期的主体。换句话说架构师要发现问题的主体，并确定核心问题。在确定业务核心生命周期以及核心生命周期的主体之后，架构师还需要对业务核心生命周期进行分析，剥离出非核心生命周期，并根据当前人员的状况，合理地分配非核心生命周期的权责。这样不同的人就可以并行且互不影响地做不同的事情，最后根据核心生命周期，把他们的工作成果组合起来，达到1+1>2的效果。

架构师绩效的反馈应该由问题的解决效果来决定。如果以很少的资源达到了很大的业务增长，那肯定是一位好的架构师，公司所节省下来的资源应该回馈给架构师，从而形成正向反馈。

如何培养架构能力？

提升驱动力

对于一个技术团队要提升系统架构能力，首先必须要有自己的技术定位，要有浓厚的技术氛围、明确的技术愿景，只有这样才能留得住热爱技术的工程师。其次是要制定团队技术能力的提升计划，特别是系统架构能力的提升。而提高系统架构能力往往又需要实际的推动力，推动力一般来自三方面。

• 客户的实际需求。比如客户要求系统能支持1万并发请求，但实际压测仅支持1000，那这时候要进行技术改进，局部改进或者重构。阿里的双11就是阿里技术发展的强大推动力。

• 测试数据。比如在进行性能测试时发现一个测试数据很诡异，首先想到可能是数据库问题，为什么操作数据库花费了这么多时间？然后是算法或者逻辑的问题。业务发展到一定阶段都会遇到“飞机在全速飞行的前提下换引擎”的问题，是在现有框架下对两个业务分别改造，还是推翻现有模式建立一个技术共享的新模式？这不仅是对架构能力的挑战，更是对团队的协同作战能力的考验。

• 外部公司技术资料。例如参加顶尖科技公司主办的技术大会、顶尖科技媒体主办的技术交流会，或者阅读技术大牛公司或者个人出版的图书、IEEE论文等，这些都能给技术管理者一些灵感，帮助他们创造更好的技术产品。多了解外部的技术发展状态，对于明确或纠正团队的技术发展方向很有利。

技术团队需要不断地前进，作为技术人员的我们也要学会给自己设置技术愿景，只有不断给自己设置愿景的人，才会不断地尝试提高自己的技术能力、设计能力。

步步为营

我们需要一步一步地走，好的架构都不是一蹴而就的，而是一步步完善的。

以一个电商架构的演进为例，一个电商站点刚开始时流量不高，只需要一个单体架构就能支持了。

随着网站曝光率越来越大，流量上来了，为了应对流量，这时候可以做集群进行流量分散，以承载更多流量。

一段时间过去了，流量变得更大了，我们需要做进一步的架构优化，进行数据库读写分离。

好了，流量继续增加，为了提高性能，我们要引入缓存来优化了。

网站曝光量越来越大，数据量越来越大，考虑进行分库分表。

流量还在持续增大，这时候要考虑进行微服务拆分了。

从这个例子可以看到，架构模式是随着业务需求的变化而不断变化演进的，这也和上面我们说的业务需求的驱动力是相对应的。

从一个程序员到架构师是一个很大的变化，架构师需要从大的方面考虑，而不只是考虑这个模块该用哪种设计模式去开发。总的来说，想要成为架构师，需要有耐心，不断学习，拓宽自己的视野，不要局限于自己眼前的项目，多关注开源技术，多关注热门技术社区的新动向。

创新思维

批判性思维是创新过程中最显著的特征。

什么是批判性思维？批判性思维是通过否定来寻找更好的做事方法。

程序员应该要拥有一定的批判性思维。

创新的4个核心要素：

• 批判性思维则是通过否定来寻找更好的做事方法。

• 批判性思维需要准确的问题定义。

• 问题的定义有赖于概念系统的建立。

• 在初始阶段，概念模型的正确与否是次要的，更为重要的是要有一个概念模型，然后这个概念模型可以随着认识的深入而不断演化。

这期的架构思维就聊到这，篇幅比较长，希望大家读完也能有所共鸣。

我是Seven，一个不懈努力的程序猿，希望本文能对你有所裨益

为什么说在西游记项目组里沙僧最容易被开除？

如何看懂Apache Log4j 远程代码执行漏洞原理？

细数Java8-14的那些经典特性，语言的车轮正在滚滚向前...

要使用消息队列，以下这些你都要知道...

GC如何判断一个对象是否为垃圾？深度剖析三色标记算法原理

是什么决定了一个项目是否成功？

Seven的代码实验室

一只不懈努力的程序猿，通过代码实验洞悉技术的本质。