共计 9811 个字符，预计需要花费 25 分钟才能阅读完成。
一 前言
架构设计依照施行过程可分为工程架构，业务架构，部署架构等多个维度，一个好的零碎架构规范应该具备可扩大、可保护、可靠性、安全性和高性能等特点。只管这些特点大家都熟知，但在理论落地时，咱们更为迫切的想晓得实现这些要求的要害门路，以便在架构设计中融入这些特点。只有这样，能力确保零碎可能适应将来的业务增长和交付效率。本文将重点围绕如何进行工程架构设计开展探讨。
二 价值为先
在计划呈现歧义时，站在产品（商业）价值的视角扫视计划并作出决策，这一点十分重要；
技术容易陷入的两个误区：
1.来者不拒：产品经理提的需要，都是有情理的，我负责实现；
2.技术驱动：这种技术实现特地奇妙，让产品个性适配于技术实现；
以上两类误区，很容易让研发对产品价值的了解造成偏差，容易对后续的技术迭代产生颠覆性的影响。站在产品（商业）价值维度，可能让合作各方站在平等的视角看问题，不仅可能容易达成共识，也能更好的为业务演进和技术迭代做好布局。
软件也是产品，在零碎设计的时候，也会围绕着市场，组织，资源几个生产因素开展。
1. 市场就是咱们产品的指标，这是咱们的搭建零碎的基本；
2. 组织就是围绕着产品交付过程中的资源协调和保障机制；
3. 资源就是围绕着产品投入的机器，人员，工夫，经营等生产资料；
软件开发是围绕着投入产出比（ROI）开展的生产经营流动。可扩大，可保护，可靠性，安全性，高性能都是咱们产品的个性，每一项个性都须要投入相当的老本来实现。
1. 跑车速度快，是最突出的个性，它就义了路况适应性，乘坐舒适性和驾驶安全性；
2. 越野车突出的是路况适应性，它就义了速度和舒适性；
3. 轿车在路况适应性，乘坐舒适性，驾驶安全性和行驶速度之间做到了绝对平衡，成为了常见的代步工具；
正所谓：“将军赶路，不追小兔”，总是有所取舍。咱们不谋求打造一个完满的简单零碎，但能够在限定的前提下谋求卓越！
三 架构设计
架构模式形容了软件系统中各个组件之间的关系、职责和交互方式，从而为软件设计提供了一种标准和束缚，进而进步软件生产效率。次要体现在一下两个方面：
1. 帮忙开发人员更好地组织和设计软件系统；
2. 促成团队之间的合作和沟通，使得团队成员更容易了解和分工；
3.1 工程框架
新零碎往往从搭建我的项目的工程根底框架开始，包含目录构造、配置文件、代码模板等工程束缚，次要用来标准我的项目构造、职责边界和代码格调，从而进步代码品质和可维护性。具体包含以下几个方面：
1. 约定了各个模块的依赖关系和交互方式；
2. 标准接口交互协定；
3. 对立异样编码、捕捉和解决；
4. 标准日志打印格局；
5. 其它公共标准束缚；
上面就最罕用的分层架构和 DDD 架构给出一些实际思路。
3.1.1 分层架构
分层架构有多种形式，例如 MVC、六边形架构等，它们是随着业务和技术的倒退逐渐演变而来的。
在互联网初期，因为计算机硬件性能差、网络速度慢、存储老本低等因素的限度，互联网产品的状态绝对繁多，只能实现简略的门户网站、BBS 论坛等绝对简略的产品。过后的技术架构没有分层的概念，次要应用 ASP、JSP、PHP 等脚本语言，在这些脚本文件中混合着编写 HTML、JavaScript、CSS 和 SQL 是很常见的。随着互联网技术的倒退以及更多简单业务的线上化诉求，动静脚本语言的劣势也逐步浮现，以 JSP 脚本语言为例：
1.复杂性：JSP 脚本语言的开发和保护比较复杂，因为须要解决 Java 代码和 HTML 代码的混合；
2.安全性：JSP 脚本语言容易受到 SQL 注入攻打等安全漏洞的影响，从而导致系统不稳固或被攻打；
3.扩展性：脚本语言的可扩展性比拟无限，因为须要在 HTML 页面中间接编写 Java 代码，从而导致系统结构不够清晰；
为了解决上述问题，呈现了各种框架，如 Spring、Struts 等。这些框架逐步代替了 JSP 脚本语言，同时也提出了分层架构的概念。其中最典型的就是 MVC（模型、视图和控制器）架构模式，其次要目标是解耦应用程序的不同局部，使其更易于保护和扩大。具体实现形式如下：
1.拆散关注点：将应用程序分为三个次要局部，使得每个局部都能够独立开发和测试，从而更好地拆散关注点；
2.进步可维护性：因为做了三个层面的关注点拆散，更容易保护和批改应用程序的不同局部；
3.进步可扩展性：展现逻辑和业务逻辑管制拆散，更容易扩大应用程序的不同局部；
在多层架构中，视图层通常会应用基于模板的框架（如 Thymeleaf、Freemarker、Velocity）或前后端拆散的技术栈（如 Vue.js、React）。这些技术的演进可能解决更加简单的问题，如金融保险和电子商务等场景，但同时也会带来一些新的痛点：
1.学习曲线较平缓：因为 MVC 架构模式须要开发人员理解和把握多个概念和技术，学习曲线较平缓；
2.进步了复杂性：因为 MVC 架构模式须要将应用程序分为多个局部，减少了应用程序的复杂性；
3.减少了开发工夫：须要进行更多的测试和集成工作，减少了开发工夫；
为了进步产品交付效率并升高技术门槛，古代研发工作通常会拆分为多个岗位，包含前端开发、后端开发、品质测试、运维保障等。这些岗位须要协同工作，共同完成产品的研发工作。为了保障多业务线和多岗位之间的有序合作，无效个管控过程危险，通常还会设有项目管理岗位。
MVC 架构是对整个业务实现进行了关注点拆散，但在更为简单的大型项目中，特地是多人合作，多业务并行的场景下，MVC 架构往往显得力不从心。此时须要对其进行更细粒度的拆分，以达到多业务线并行，而不会存在大的工作资源抵触问题。当然，不同的业务场景会有不同的拆分模式，最常见的拆分模式是 多层架构模式，如下图：
通过横向的分层架构咱们实现了研发分工协作，所有的教训束缚在这里得以体现。 上图中，将管制层进行了二次细分。也能够依照理论利用场景进行从新调整。比方 web 模块是否依赖 RPC 模块就能够在 POM 文件中进行限定，如此以来，大家依照既有的工程约定，施行开发工作就能够了。
简略形容一下各个模块分层的作用：
1.数据拜访层：将业务逻辑层和数据存储层进行解耦，属于模型层的领域。它与底层数据源（MySQL、Hbase，EleasicSearch）进行数据交互，常见框架有：MyIbatis，Hibernate 等；
2.近程调用层：即 RPC 层，与 DAO 层平行的数据拜访层，区别是它是通过第三方接口或平台服务提供拜访能力。和 DAO 层的区别在于数据归属权和畛域事务控制权；
3.事务管理层：也叫通用业务解决层，它有如下特色:
◦对下层业务，进行业务和技术共用能力下沉，比方：多个业态的对立订单生产能力，通用的分布式事务一致性的解决方案等；
◦对上层依赖，组合 DAO 层和 RPC 层的能力，实现繁多业务的事务管理；
◦对于简略的业务零碎，Manager 层的职责能够由 Service 层代替；
4.业务逻辑层：绝对具体的业务逻辑服务层，次要负责业务流程的组装和编排，真正的灵活性和扩展性次要体现在这里；
5.申请解决层：次要是对访问控制进行转发，入参整形，出参定制等，其职责是间接面向的是各个终端或第三方服务方；
6.凋谢服务层：定义对外提供的 RPC 服务，性能职责和 Web 层相似，同样须要思考网关安全控制、流量管制等因素；
7.终端显示层： 各个端的模板渲染并执行显示，velocity，React，IOS 挪动端等；
传统的软件设计往往会导致各个组件之间严密耦合，从而导致代码难以保护和扩大。六边形架构模式是分层模式的一种变体，通过将业务逻辑与框架、库等技术细节拆散，从而实现了松耦合的设计，使得代码更易于保护和扩大。 同时，六边形架构模式还能够帮忙开发人员更好地实现单元测试和集成测试，从而进步软件品质。这在各种技术中台性质的业务场景下，十分有用，如下图：
3.1.2 DDD 架构
畛域驱动设计（DDD）是一种软件开发办法，它以业务畛域为核心，通过深刻了解业务畛域的常识，将业务逻辑封装在畛域模型中，以此来实现更好的代码可维护性、可扩展性和可重用性。
DDD 属于涣散的分层架构，每层职责和作用如下：
1.用户接口层：web 申请，rpc 申请，mq 音讯等内部输出申请；
2.应用层：负责编排、转发、校验等，这与 MVC 中的 service 层中存储着大量业务逻辑有所不同；
3.畛域层：也就是模型层，负责表白业务概念，业务状态以及业务规定。蕴含了该畛域所有简单的业务知识形象和规定定义，蕴含实体，值对象，聚合（聚合根），畛域服务，畛域事件，仓储，工厂等；
4.基础设施层：为畛域模型提供长久化机制及其它通用技术支持能力，如音讯通信，通用工具，配置等实现；
为什么 DDD 长年热度不减，但在咱们理论的零碎开发过程中，却很少有齐全落地的我的项目呢？或者说 MVC 架构格调的零碎很常见，但 DDD 架构格调的零碎却很少见到。这得回归到 DDD 自身：它是解决 简单业务 的一种 软件开发方法论。
如果将一般的 CRUD 业务零碎也依照这套模式实现，反而会减少零碎的复杂度。总体来说，DDD 模式实用于以下几种场景：
1.反对解决简单业务逻辑场景：当应用程序须要解决简单的业务逻辑时，DDD 能够将业务逻辑封装在畛域模型中，从而更好地反映业务需要和业务流程，升高了零碎架构的复杂度；
2.高度可保护和可扩展性场景：DDD 将应用程序拆分成多个子域，每个子域都有本人的畛域模型，这样能够更好地治理业务复杂性；
3.须要疾速迭代和交付的场景：每个子域都能够独立开发、部署和扩大，这样能够使得团队能够疾速迭代和交付应用程序；
为了评估业务的复杂程度，咱们须要从多个方面进行思考，业务流程、产品规定、数据结构以及需要变动频率等。个别状况下，采纳这种架构模式须要谨慎的评估，因为施行这种开发模式会面临以下几个挑战：
1.须要深刻了解业务畛域：DDD 是一种以业务畛域为核心的设计办法，因而须要深刻了解业务畛域的常识，能力设计出合乎业务需要的畛域模型；
2.须要跨部门合作：施行 DDD 须要跨部门合作，包含业务人员、开发人员、测试人员等，须要大家独特单干能力达成共识；
3.技术难度较高：DDD 须要了解很多简单的概念，如畛域事件、聚合根、畛域服务等，须要开发人员具备肯定的技术水平；
总之，无论是团队合作模式、集体技术能力要求、业务共识的达成，各个方面都具备很大的挑战。但这并不意味着 DDD 在一般业务零碎中，就没有用武之地。其解决简单问题的思维依然可能让咱们受害。罕用的工具框架，如 CQRS 框架、事件驱动架构和微服务框架，都有 DDD 的设计思维的影子。
以微服务架构为例，先看以下几个问题：
•微服务应该如何设计呢？
•微服务是依据什么进行拆分的？
•微服务是如何划分边界的？
微服务拆分的太细，更多的服务会进步经营和治理难度；拆的太粗，性能耦合度高，在灵活性和扩展性方面又存在有余。所以这是一个比拟辣手的问题。
确定业务和利用边界，是解决微服务窘境的要害。而 DDD 就很好的解决了业务边界的问题，它提供了一种划分业务畛域范畴的方法论。
微服务就是将应用程序拆分成多个子域，每个子域都以微服务的形式对外开放能力。微服务将简单的业务流程和规定限定在畛域范畴内，即外部实现各自的畛域模型和数据存储。从应用层看，这标准并对立了畛域服务的实现形式，大大简化了代码逻辑，更好地治理了业务复杂性。
3.2 技术选型
工程架构的搭建除了根底框架外，还有一部分重要内容，就是各类根底中间件的抉择，也就是咱们常说的技术选型。上面联合示例跟大家开展讲述一下，对于技术选型须要关注的要点。
3.2.1 业务需要
理解业务需要，明确零碎的性能、性能、平安以及将来的扩大需要。
示例：在零碎模块划分的时候，有的零碎会拆分成【WEB】+【JSF 微服务】两组利用进行离开部署，而有的零碎只会部署一个【WEB】利用。这两头的判断规范是什么？拆出来【JSF 微服务】的作用是什么？
能力复用：微服务层具备更通用的模型设计，具备更强的多业务场景复用的能力。在服务经营的过程中，能够依照业务进行垂直部署；
资源隔离：按业务垂直部署，能够更精细化的优化网络，机器等硬件资源。另一方面，将下层 WEB 利用与底层的微服务进行资源隔离，同样能够实现更精细化的资源分配。
综上所述：如果你的服务没有多端复用和资源经营的需要，就没有必要拆开部署，减少调用链路和机器资源的多倍投入。反之，进行服务拆分，好处则更大。
3.2.2 技术个性
评估不同技术的个性，包含可用性、性能、安全性、可扩展性、可维护性等方面。
示例：已经遇到过一个零碎，底层的存储层用的是 db4o（一款开源的面向对象数据库），这个中间件领有很多长处：
•间接以存对象的形式存取数据；
•不须要数据库服务器，只须要一个数据文件，且 dll 大小仅为 300 多 k；
•数据查问，操作简便且功能强大，甚至不须要应用 SQL；
但这里还是不倡议应用它，因为咱们是分布式集群服务，这个数据库文件只能存储在单机下面，即存在单点故障问题，这是最致命的。有时候为了补救相似的缺点，你可能须要破费更多的老本。反过来说，如果是作为嵌入式数据库，利用在某些单片机上，它的这些劣势就可能显现出来了。
3.2.3 社区反对
思考技术的社区反对水平，包含是否有沉闷的社区、是否有大量的文档和教程、是否有成熟的第三方库等。
示例：散布式调度框架中 tbschedule 算是开源比拟早的了，然而开源之后很早就没有人保护了，如果在一般的业务中轻度应用，应用层做好监控，应该问题不大。但如果是作为根底中间件大范畴的应用，显然它在调度过程可观测性方面，zk 重连机制方面，调度异样主动复原等方面急需降级优化。但事实是社区早就曾经进行保护了，这就是一个比拟麻烦的事件。
3.2.4 团队技能
依据团队的技能程度抉择适合的技术，防止应用过于简单或生疏的技术。这一点十分重要，否则前期的保护老本和迭代效率晋升将成为一个大的难题。
示例：Cobol 语言是上个世纪 70 年代，一种被广泛应用于金融行业的编程语言。它能够解决大量的数据和简单的计算，而且有着高度的可靠性和安全性。直到 2015 年，它还运行着寰球 43% 的银行零碎和 95% 的 ATM。
但在 2023 年 3 月份，日本就发表，打算全副银行零碎 Cobol 转 JAVA 语言。起因就是精通这门古老语言的技术人员十分稀缺,Cobol 生态跟不上机器学习、星散成等新的倒退了，整个零碎的保护老本和迭代效率远远低于古代的 JAVA 生态体系。
3.2.5 老本效益
评估不同技术的老本效益，包含开发成本、运维老本、许可证费用等方面。
1. 如果有成熟的开源插件可用，咱们应该尽量应用它们，而不是从新创造轮子；
2. 对于其余团队曾经实现的工作，咱们须要思考是否能够复用；
示例：以后大多数技术中间件都须要 JDK8 或以上版本的反对，因而在进行技术选型时，咱们须要思考适合的 JDK 版本。随着 Spring Boot 3 的公布，其默认反对的 JDK 版本为 17，不再反对 JDK8。这对于新零碎而言，抉择新版本仿佛更为适合。而对于存量零碎，则须要思考新版本升级对于零碎的革新老本以及带来收益是否匹配，而不是想当然的谋求新技术。
3.2.6 危险评估
评估不同技术的危险，包含技术成熟度、安全漏洞、依赖关系等方面。
示例：Fastjson 是开源 JSON 解析库，它能够解析 JSON 格局的字符串，反对将 Java Bean 序列化为 JSON 字符串，也能够从 JSON 字符串反序列化到 JavaBean。具备执行效率高的特点，利用范畴宽泛。当初，在进行技术选型的时候，就须要当心了，起因就是最近两年它频繁的爆出安全漏洞，依赖的利用须要跟着频繁的降级版本，修复破绽。这还只是表象，更为深层次的起因是显现出的平安保障方面的有余，这在技术选型时，是不得不思考的因素。
3.2.7 小结
在抉择技术计划时，没必要对最新的，最热门的技术抱有执念，综合思考业务需要和团队技能储备等多重因素，以抉择最适宜的计划为宜。当然，为了适应一直变动的业务需要和技术发展趋势，也要有及时进行技术评估和更新的意识。
四 标准共识
共识的重要性在于确保团队成员之间的沟通和了解达成统一。通过制订标准和流程，能够缩小反复工作和谬误，防止抵触和误会，这有利于进步研发效率和品质。
4.1 数据分层
4.1.1 对象转换
在分层架构中，各层之间存在相互依赖和援用，数据则通过参数对象进行传递。为了确保每一层内部结构的稳定性，咱们须要进行防腐设计。这是实现高内聚，低耦合的要害。
示例：模型层一张表有 20 个字段，那么对应的 PO 对象就有 20 个属性。但终端显示层只有显示 10 个字段，申请解决层（Web）在获取数据时，没有必要把整个 PO 对象传递回来，这时咱们就能够用只有这 10 个属性的 DTO 对象来传递后果到申请解决层，这样也不会裸露服务端表构造和一些敏感数据。
数据防腐设计罕用的伎俩就是各层定义本人的数据结构，常见的有：
1.VO（View Object）：视图对象，次要对应界面显示的数据对象；
2.DTO（Data Transfer Object）：数据传输对象，次要用于近程调用等须要大量传输对象的中央；
3.DO（Domain Object）：畛域对象，就是从事实世界中形象进去的无形或有形的业务实体；
4.PO（Persistent Object）：长久化对象，它跟长久层（通常是数据库）的数据结构造成对应的映射关系；
在理论的开发中，为了不便起见，不肯定须要为每个服务层定义本人的数据对象，能够依据理论状况来灵活处理。例如，在某些简略的业务场景中，能够跳过 DO 层对象，间接将 PO 对象转换为 VO 对象。
4.1.2 对象复用
在迭代了许久的零碎中，很容易碰到一个问题，就是一些对象的作用域失控了，其典型特色有：
1. 一个入参对象，有好几个办法在共用，调整一个属性值定义，影响范畴大，危险高；
2. 间接应用 Map 容器作为本人服务的入参或出参对象，没有人能讲得分明容器外面到底有多少内容；
3. 一个对象定义外面，存在着多个类似的属性定义。新的需要来了，为了升高危险，索性就再新定义一个，如此周而复始；
对象的作用范畴失控问题会导致系统整体的稳定性和迭代效率显著降落。这个问题通常是一个迟缓的积攒过程，在人不知; 鬼不觉中造成。其弊病，往往在大的零碎调整时集中暴发。
解决此类问题，能够从以下几个方面动手：
1.预防：在进行架构设计的时候就给出清晰的标准定义；
2.发现：定期进行设计和代码评审，发现问题后，及时纠正；
3.止损：发现了此类零碎，须要思考微重构，避免继续腐坏上来；
4.复盘：适时的对系统进行定期复盘，对好的演进进行激励，对有余的进行疏导，养成好的技术气氛；
4.2 异样治理
4.2.1 捕捉异样
异样捕捉也容易走两种极其，一种是每个办法都 try-catch，一个办法里有多组。另一种是整个链路都没有一个 try-catch，处于裸奔的状态。那么到底该如何进行异样捕捉呢？先看一下捕捉异样的目标：
1. 对异样进行预判解决，让流程得以继续下去；
2. 疾速发现并定位问题，保证系统的稳定性；
基于异样解决的目标，对应的解决策略也就清晰了：
1. 如果是为了流程继续下去，那么异样就必须在对应的节点捕捉并解决；
2. 如果是为了疾速发现定位问题，那么就能够通过在调用入口处进行对立捕捉解决，异样堆栈里会有具体的异样的起因；
总之，异样是须要捕捉的，然而具体须要在哪里捕捉，如何捕捉，咱们能够依照目标进行灵活处理。
4.2.2 解决异样
1. 业务和零碎异样要留有痕迹，不便日后问题定位和统计分析，比方日志，音讯等；
2. 对各类异样进行有规定的编码，能够疾速定位问题，不便设置应急预案，规定能够参照 HTTP 的申请响应编码；
3. 打印异样堆栈信息，这是疾速定位问题起因的重要伎俩；
4. 对异样数据进行纵向统计和比照，不便识别系统衰弱状态；
4.3 日志治理
1. 对立日志框架，倡议应用 SLF4J 日志门面框架，具体实现抉择 Log4j2、Logback 等；
2. 配置日志框架，包含日志输入格局、输入地位、输入级别，输入形式（异步打印）等；
3. 应用不同的级别来记录不同类型的信息，并别离打印到不同的文件中；
4. 定期检查和清理日志文件，以防止占用过多磁盘空间；
5. 依据须要，能够将日志信息发送到其余零碎或者进行剖析解决，以便更好地监控和管理系统；
6. 必要的状况下，建设动静调整日志级别的能力；
4.4 监控治理
1. 零碎性能监控：监控零碎的 CPU、内存、磁盘、网络等资源的应用状况，以及应用程序的运行状态。如 Nagios、Zabbix；
2. 日志监控：监控零碎和应用程序的日志信息，引入 traceId、业务身份 Id，及时发现异常情况。如 ELK（Elasticsearch、Logstash、Kibana）；
3. 安全监控：监控零碎和应用程序的平安状态，及时发现潜在的平安威逼。如 Snort、Suricata；
4. 业务监控：监控业务零碎的各项指标，访问量、响应工夫、错误率等，及时发现业务异常情况。如 Grafana、Prometheus；
5. 调用链路跟踪：能够跟踪一个申请在整个分布式系统中的调用链路，记录每个服务节点的解决工夫和状态，并将这些信息聚合起来，造成一个残缺的调用链路图，以便于剖析和排查问题。如：Zipkin、SkyWalking；
6. 监控预警：各种监控工具是辅助疾速定位问题的有效途径，要想第一工夫发现问题，欠缺无效的预警触达机制必不可少。如邮件，企业微信，短信，电话等；
4.5 合作共识
4.5.1 HTTP 服务申请都应用 POST 形式？
最近，咱们的 APP 遇到了一个问题。在某些状况下，服务调用返回了“HTTP 414 URI Too Long”的响应谬误。这个问题的根本原因是 Tomcat 默认的 get 申请长度限度（包含申请行和申请头）超过了 8192 个字符。为了解决这个问题，有以下几种计划：
1. 通过批改 server.xml 文件中的 Connector 元素中的 maxHttpHeaderSize 属性值（比方：改为 16384）来放宽限度；
2. 将服务的申请协定由只反对 GET 形式，调整为同时反对 POST 申请形式，因为 POST 申请形式没有这个大小的限度；
3. 精简 Header 申请参数，标准并限度 cookie 和业务参数的写入；
计划一，扩充 Tomcat 的容器限度，短期看起来能够，然而这是一个公共问题，要调整的利用容器可能须要成千上万台，而且治标不治本。
计划二，将所有 GET 申请形式，调整为同时反对 POST 申请形式，波及到的利用又有成千盈百个，工作量也不少。
计划三，精简 Header 申请参数，这个最为正当和稳当，也是呈现问题的实质起因，然而波及到两个 APP 互相交互以及几十上百个部门协同梳理和革新，难度同样很大。
如果是你，该如何抉择计划呢？
4.5.2 前端不做逻辑解决，只做数据渲染？
前端视角：因为 APP 发版，波及到版本审核，用户下载更新等流程，一方面周期长，另一方用户能够回绝降级。这就导致前端研发提出来，“前端不做业务逻辑解决，只做数据渲染”的口号。如果前端承接了业务逻辑解决，一方面，出了 bug，想要修复的代价很高，如果用户不降级版本甚至无奈修复。另一方面，前端承接了局部业务逻辑，将会和后端呈现职责边界难以划分分明的状况，给合作埋下了的隐患。
后端视角：一个默认背景图，一句提醒文案，一个字体色彩 … 这些可预感的不会做出调整的数据，都须要咱们来下发吗？进步了数据复杂度，减少了网络带宽。而且前端也有热更新技术，容易变动的简单页面还能够通过 H5 来实现，怎么就不能做一些简略的业务逻辑了！
这又该如何进行计划抉择呢？
4.5.3 小结
很多技术问题的解决方案并没有显著的偏差性，这取决于过后的环境和立场。例如，对于 HTTP 的 GET 申请参数超长问题，最正当的解决方案是精简 Header 参数，但这须要长期的致力，而在短期内很难实现。因而，在解决以后问题时，咱们能够思考其余两种计划。同样地，对于前端是否应该解决业务逻辑的问题，咱们须要思考到咱们对 APP 的定位以及前后端各自根底能力的建设状况。好计划的评判规范应该是 ：可能低成本地解决以后问题，并且不引入新问题。
五 总结
本文具体介绍了搭建系统工程架构时须要关注的几个重要方面。基于产品的价值，做出决策。并从系统工程架构的演进、技术计划的选型、零碎标准共识的达成等方面动手，对施行过程中的常见问题给出了解决思路。最初，借用《楞伽经》中的“标月指”作为结束语，与读者共勉：“如愚见指月，观指不观月。记着名字者，不见我实在。”
