没有一种架构是可以满足所有迭代的需求的

架构并不是只限于技术选型，架构作为软件生命周期的一部分！软件的生命周期包含了迭代、维护、重构等过程，架构设计亦是如此，所以说架构是需要变化的，目的就是适应当前情况的开发场景。

而架构产生的时间，必定是受到当时的约束条件，如人力、团队技术积累、时间、业务定位等等需求。所以，当前架构可能并不能满足未来的需求，我们要开放对待这个问题，只要当前的架构符合一定的设计原则，未来进行架构的演进就不是问题。

“架构”这个词解释也没有一个明确的定义，每个层级，每个场景都有自己的解释，所以到底什么是架构呢？

定义

软件架构（software architecture），是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

其实软件开发和盖一栋大楼一样，都需要规划、设计、实施等一系列的阶段，最开始设计建筑图纸，主体架构，还要考虑绿化、材料、安全等因素。经过一系列的决策，才有一套成熟的建筑施工方案，按照规范建造，才能保证质量和速度。

而开发一个软件或前端工程也是一个“建筑”的过程,我们要通过业务来定位系统间的关系，讨论技术栈和框架的选用，根据当前团队的技术水平进行技术的选型、考虑各个模块间的界限和交互，上线部署策略，问题回滚策略等一系列的决策才能设计出符合当前情况的技术架构。

前端架构

前端崛起之后，也出现了前端架构这个概念，但是，在开发过程中需要怎样的架构呢？大体来看基本要求点如下：

• 符合当前的业务定位
• 前端架构必须具有可实施性
• 必须匹配当前技术储备
• 有足够的人力资源去完成
• 具有可伸缩、可扩展性

【因地制宜】应该是开始设计架构的基本准则，每套架构的产生都有他的外界因素影响，所以，各个公司，各个团队之间的架构不能照搬，如果强制搬过来，可能会适得其反，就像你那 alibaba 的技术架构去搬到 初创 公司，那是根本行不通的，人员、资源不匹配，是没办法去实施架构的。

因此我们在项目前端开发的生命周期中期望的架构应该具有哪些要点呢？

• 准确的业务定位，业务可能是影响架构的主要因素之一，所以我们要找准业务上的定位
• 明确与其他系统之间的关系，确定与其他系统的层次关系，相互间的通讯依赖等
• 设计好系统内子模块之间的关系，如A业务模块需要与B模块交互，该采取怎样的方式
• 基础模块明确，项目中，必定含有基础模块去提供一些公用的方法，数据去提供给各个子模块
• 组件规划，这就是再细一层的规划了，制定组件的交互方式，开发范式
• 开发规范和上线流程，用于指导开发中的过程

架构设计

• 收集利益相关者的需求，产品经理、业务人员、项目负责人等
• 与相应技术人员进行讨论，确定架构上的潜在限制和要求
• 寻找可行性的技术方案
• 细化技术方案细节，确定一些功能列表中的技术可行性
• 确定风险点
• 与技术人员反复讨论，集合大家意见
• 对技术方案进行demo的概念验证
• 结合当前业务，细化架构的部分实施细节
• 进行排期

架构设计原则

1. 不多也不少：不做多余的设计，也不缺少核心部分

设计过少则为设计不足，会使一个框架的伸缩性和扩展性不强，不能灵活的面对即将产生的业务需求的迭代。

设计过度也不一定是件好事，针对未来的技术框架或者需求的变更，我们不能保证目前的架构就一定能兼容这些变化，过度设计反而会让我们一会的架构重构产生很多无用的开发变更，增加成本反而得不到相应的输出价值。

2. 演进式：不断的演进以架构适应当前的环境

适应环境能够生存下来的物种，并不是那些最强的，也不是最聪明的，而是那些对变化做出快速反映的。 -达尔文

演进事架构是指在开发过程中，预先设计好重要的部分如系统模块通信，功能模块划分，具体组件颗粒度等，然后在编码过程中，再进行细颗粒度的划分，遇到不适合的地方，进行快速的反应，找到最优解，最理想的状态是，20%的计划，80%的演进设计

3. 持续性：长期的架构的改进

持续性和演进式有一定的共同性，演进式的目标是在开发过程中进行架构的细化，持续性则指在迭代过程中进行框架的进阶，在迭代过程中，难免会出现架构不符合当前状况的情况，我们要灵活应对，进行持续性的优化，这样才能在迭代开发过程中，做到最优框架的目的

衡量架构的合理性

架构为业务服务，没有最优的架构，只有最合适的架构，架构始终以高效，稳定，安全为目标来衡量其合理性。

1. 业务需求角度

• 能解决当下业务需求和问题
• 高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题
• 前瞻性设计: 能在未来一段时间都能以第2种方式满足业务，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。

2. 非业务需求角度

• 高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。
• 文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。
• 可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。
• 高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。
• 安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

常见架构误区

1. 架构专门由架构师来做，业务开发人员无需关注。架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。
2. 架构师确定了架构蓝图之后任务就结束了。架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。
3. 不做出完美的架构设计不开工。世上没有最好架构，只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车，而是从单轮车→自行车→摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？
4. 为虚无的未来埋单而过度设计。在创业公司初期，业务场景和需求边界很难把握，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。不要过多考虑未来的扩展，说不定功能做完，效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰，是应该适当的考虑未来的扩展性设计。
5. 一味追随大公司的解决方案。由于大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯就是这么搞的”。大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。
6. 为了技术而技术。技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将技术发展引入崎岖小道，架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑，理想与现实需要折中。