一 前言
架构规划依照施行进程可分为工程架构，事务架构，布置架构等多个维度，一个好的体系架构标准应该具有可扩展、可保护、可靠性、安全性和高功能等特色。尽管这些特色咱们都熟知，但在实践落地时，咱们更为火急的想知道完结这些要求的要害路径，以便在架构规划中融入这些特色。只有这样，才干确保体系能够习惯未来的事务添加和交给功率。本文将要点围绕怎样进行工程架构规划打开讨论。
二 价值为先
在计划呈现歧义时，站在产品（商业）价值的视角审视计划并作出决议计划，这一点十分重要；
技能简略堕入的两个误区：
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的定位以及前后端各自根底才干的建造状况。好计划的评判标准应该是 ：能够低本钱地处理当时问题，并且不引进新问题。
五 总结
本文具体介绍了建立体系工程架构时需求关注的几个重要方面。根据产品的价值，做出决议计划。并从体系工程架构的演进、技能计划的选型、体系标准共同的达到等方面下手，对施行进程中的常见问题给出了处理思路。最后，借用《楞伽经》中的“标月指”作为结束语，与读者共勉：“如愚见指月，观指不观月。记取姓名者，不见我实在。”
