ai和传统的软件架构一样吗「软件架构系统架构」

大家好，ai和传统的软件架构一样吗「软件架构系统架构」很多人还不知道，现在让我们一起来看看吧！

人工智能并不是一个新概念，40年代维纳的《控制论——关于在动物和机器中控制和通讯的科学》就是人工智能。但早年的人工智能受限于计算能力，更多在解决模型的计算速度和精度上，近年来随着云计算技术的发展，计算能力提高了，随着大数据的发展，更复杂的计算问题可以用更多的数据进行修正，人工智能的可用性大大提高。但是我们从目前人工智能应用的情况可以看到，人工智能并不能替代人类，例如在图像识别、语音方面的突破，仅仅是让机器更加聪明而已，还远远没有达到人类的程度，作为人类的智能助手更加合适。

一：理清人工智能、机器学习、深度学习、统计等基本概念之间的关系

把人工智能的方法应用到软件中，我们先梳理清楚几个概念之间的关系：人工智能（Artificial Intelligence）是一个大的概念，是让机器像人一样思考甚至超越人类；而机器学习（Machine Learning）是实现人工智能的一种方法，机器学习最基本的做法，是使用算法来解析数据、从中学习，然后对真实世界中的事件做出决策和预测；深度学习（Deep learning）又是机器学习的一种实现方式，他是模拟人神经网络的方式，用更多的层数，更多的神经元，然后给系统输入海量的数据，来训练网络。而统计学是机器学习和神经网络的一种基础知识，从传统分工来看，统计学一般是数学、统计等专业研究的方向，而机器学习是计算机科学的研究方向，但是目前大家的研究成果越来越殊途同归，有统计学的大师就认为统计实际上一直在从事机器学习的工作。

对于深度学习、统计的专家来说，他们更加关注于模型、算法等等，找到可以普适性解决问题的办法，而对于我们应用来说，具体的算法实现不需要我们考虑太多，而是找到适合的场景、合适的模型、匹配的算法，所以，应用人工智能实际上是一个计算机、统计、知识工程、行业知识的一个交叉应用，在经常涉及到的应用中，我一般在处理结构化、半结构化数据时优先考虑传统统计学的方法，例如分类、数据相关性、回归等，而处理非结构化数据时（例如图像、视频、文本）优先考虑深度学习的方法，但这些方法也需要有统计学知识。所以，需要补课：线性代数、数理统计、Python，我觉得《机器学习实战》这书入门不错，上述几方面知识都介绍了。

应用人工智能实现增强智能的三个层面

应用人工智能的时候，人们会有一个误区，总是希望得到一个意想不到的结果，也就是希望探索出新知识。经常有人问我，得到的结果好像没有什么我不知道的，我说这就对了，因为你是专家，要是计算机得到的结果都是不可知的，你怎么能相信他，例如AlphaGo下的棋，绝大多数都是人类已知的，非常少非常少的情况下，下出一招另类，这已经是一个顶天星的水平了。很多人失望了，这还有啥意思，其实意义很大：

（1）计算机可以让常人快速获得以往专家才能具备的知识，例如有经验的客户经理，肯定非常了解客户的情况，谁是优质客户，谁需要什么产品等等，不需要计算机，但是通过用户画像等人工智能的手段，计算机可以让经验不够丰富的人，也具备了上述经验，这个做法价值就非常高，毕竟专家是少的；

（2）帮助专家减少重复性的工作，例如医生在做病理检测时，绝大多数没有生病的情况和有典型病理特征的情况，机器都可以提醒医生，节约医生的宝贵时间。如此看来，我们就会理解，人工智能不是替代人，而是给人类增加一个智能的助手，是增强智能（IA Intelligence Augmentation）。

计算机作为一个智能助手，可以在不同层面和手段帮助我们，我把他分为机械智能、实现意图的智能和创造意图的智能三个方面：

（1）机械智能，我们目前从事的主要工作都是这个，事先设定规则（代码也是规则），让计算机完成大量重复计算，充分利用计算机的计算能力，替代人的手工劳动，这是一个以规则为核心的模式，而这些规则来自于人现有的知识；

（2）实现意图智能，人知道最终结果是什么，但是并不告诉计算机采用什么样的规则计算，通过大量数据训练计算机找到规则，然后再让计算机完成大量重复计算，计算机究竟找到的规则是什么，有可能人并不一定能理解，其实往往也不需要理解，把计算机当成了黑盒；

（3）创造意图智能，也就是让计算机自己找到人并不知道的新知识，这也是我们最向往的场景。

从具体的实现层面看，第一种情况无疑是最多的，我们需要提炼总结规则，用好第一种情况很重要，第二种情况以前相对少一些，但恰恰是目前需要改进的，在第二种情况下我们往往优先用统计学的方法处理结构化、半结构化数据（例如格式化日志），用深度学习的方法处理非结构化数据，这就需要让我们的团队具备人工智能的思维。

实践人工智能应用需要新思维，不能再用规则理解计算机实现智能的方式

实践人工智能，需要在在思维上进行调整。我们往往习惯于用制定规则的方式指挥计算机，输入、计算规则和输出结果都是已知的，也就是我上面说的机械智能方式。但后两种模式就不是规则方式了，因为规则是计算机找到的，这也就是经常说的数据训练。这里我举一个我们自己实现的例子，让大家理解一下什么是模型、算法和数据训练。

先说一个背景，我们在梳理现有企业数据架构的时候，需要建立数据间的关联，用人进行梳理费工费力，我们就打算用计算机自动完成一部分，然后人工修正，这就是一个增强智能（IA）的例子。这里面就有一个情况，如果数据库中没有建立外键，如何把这种实际的外键关系找出来，我们就用这个例子解释一下机械智能和实现意图智能的方法：

（1）用规则的方式查找外键关系。首先要定义规则，外键关联的规则包括字段类型一致、长度一致、包含相同数据等等，然后在所有数据中遍历，进行匹配。这种方式需要有完整的数据，而且是否外键关系的判断规则往往有些模糊，在没有得到全量数据时有一定局限性；

（2）用统计学方法查找外键关系。首先，我们定义出字段的特征（类似用户画像），字段特征是一个向量，就是一个一维数组，包括表名、字段名、字段类型、注释、样例数据最大长度、样例数据最小长度等等，由于表名、字段名不是数值，我们要把他们变成数值，可以和同一个标准字符串作比较，也就是通过移位的方式把字符串移动成标准字符串，移动次数越少，相似度就越高，这样就得到了一个真正的一维数组（向量）了。

其次，我们拿出一部分已知关系的表和字段，作为训练样本，逐一计算两个字段之间的相关系数（相关系数的计算方法是现成的，我这里就不介绍了，一上公式我就晕，Python的发行版Anaconda里面就有，用了这个就体会到 Python 是最好的语言了），相关系数高的说明特征类似，认定为外键关系。这时候人工判断一下，如果结果不错，那这个模型就是正确的，如果结果不好就换一种相关系数计算方法，或者改变数据特征，或者对数据特征进行加工，总之，外键特征作为一个客观存在，一定能够找到符合的特征，这就是数据训练。通过数据训练，找到合适的字段特征（模型）和计算方法（算法），也可以交给计算机做处理了，把所有的外键找出来。

你看，这里没有定义规则，处理方法是通过数据训练的方式，让计算机自己找出来的，我不需要知道相关系数这玩意到底是什么意思，这就是上面说的，计算机是一个黑盒。

需要说明的事，在上述例子中，我简化了不少动作，实际上最开始还找出来很多不是外键关系的字段，例如 createTime，我们还要把这种噪音字段的特征训练出来，剔除噪音。

这个示例说明了应用人工智能时不同的两种思维模式，简单的说不能再用创造规则的方式指挥计算机，而是训练计算机自己找出规律。

上面我们分析了人工智能相应的基本概念，人工智能的几种模式以及应用人工智能时需要的思维突破，下面我们从软件架构发展和面临的挑战，看看应用人工智能时的切入点在哪里，哪里更容易爆发出人工智能的火花。

二：应对软件架构分而治之带来集成的挑战，探索智能的连接

什么是软件架构，在InfoQ出版的《聊聊架构》中讲的很清楚（感谢老王，总结非常到位），软件架构就是（1）根据问题确定系统边界；（2）按一定原则进行切分；（3）建立不同模块间的沟通机制；（4）整体性交付软件功能。可见，架构的关键是分而治之的哲学，但切分是为了软件研发、运维方便，软件的目标是整体交付，分与合存在着矛盾，这一矛盾是由集成解决的，但是集成往往是复杂的，大家在架构方面的分享，也以如何切分居多，如何集成相对较少。

集成工作的复杂度影响了复杂系统的研发

Unix的实践无疑对软件架构有着巨大的影响，做一个事情，做到最好，一直是 Unix 风格所倡导的，但“在理想世界中，Unix程序员只愿意手工打造小巧完美的软件宝石，每个都那么小巧、那么优雅、那么完美。然而现实中很不幸的是，太多复杂问题需要复杂的解决方案。仅仅十行的程序，再优雅也无法控制喷气式客机。那儿有太多的装备、太多的通路和界面，太多不同的处理机，太多不同操作人员定义的子系统，他们甚至连基本的约定都无法统一。即使能够成功地将航空系统所有的个体软件部分做的优雅，但拼装结果很可能是一堆庞大、复杂、糟糕的代码… 喷气客机的复杂是必然的。过去有个尖锐的观点，不能为简单性而牺牲功能，因为飞机必须要能飞。正是这个事实，航空控制系统并不会产生关于复杂度的圣战----Unix程序员往往敬而远之。“（摘自《Unix编程艺术》）。

不幸的是，我们面临的往往是复杂性的系统，片面理解Unix风格分而治之往往带来更大的集成难度。为了降低集成的难度，我们往往采用巨石型的系统架构，用一个大一统的方式设计系统，仅仅在系统内部进行模块的拆分，用codebase和规范进行约束，走上了和Unix风格背道而驰的道路。当性能和可维护性压力到来后，这样的系统又不得不进行拆分：我过去常常看到，当软件系统达到 100 万行代码规模时，人们会觉得维护困难，产生了强烈的拆分念头，当达到 300 万行代码规模时，人们往往再也按耐不住拆分的欲望，当达到 500 万行代码规模时，再保守的组织也会作出拆分的决定。

软件架构中复杂的集成工作需要利用人工智能方式简化下来

回顾一下解决集成问题的历史，我们会发现较早的集成架构模式来自于 Unix，就是众所周知的管道（Pipe）模式。Pipe模式将数据传递到一个任务序列中，管道扮演着流水线的角色，数据在这里被处理然后传递到下一个步骤。管道模式作为一种最基本的方式，理论上可以解决所有集成问题，但涉及到具体问题时，就需要针对不同情况做应对，针对各种复杂的情况，可以总结出更多的模式，《企业集成模式》（EIP）一书中围绕消息集成，总结出若干集成模式，可谓是消息集成的集大成式总结。

但EIP的集成模式主要针对系统间后台服务的集成，SOA架构提出了以Portal（前端集成）、BPM（流程集成）、ESB（服务集成）、DI（数据集成）以及事件/消息集成的多层面集成体系，更加系统性的为集成工作提供指导。SOA的集成方式需要一系列的集成基础设施支持，属于一种中心化的集成方式，我们可以称之为MiddleBox的方式，在微服务架构提出后，我们会采用把集成逻辑与业务功能部署在一起的去中心化集成方式，可以称之为MiddlePipe的模式。

集成方式一路演进下来，主要是集成的手段上不断翻新，多种框架和基础设施越来越多的解决了非功能需求，例如 ESB 可以解决路由、安全、流控等问题，一定程度上减少了集成的工作量。但集成的业务复杂度还存在很多，这里我列举几个常见的问题：

（1）数据的查找问题。针对业务需求，需要使用已存在的数据和服务，但在企业环境中，系统、服务、数据众多（想象一下具有10多万服务、10多万数据标准的情况），想找到适用的服务和数据，不是一件容易的事情，一般我们都要依赖专家在这方面的知识，通过总体设计指定了数据的流向，这依赖于专家的能力，专家的能力也是慢慢积累起来的。我们需要帮助业务更快速的找到数据和服务，帮助专家快速实现积累，减少重复劳动。

（2）数据的适配问题。通过服务方式进行集成，原子服务往往需要大量的输入参数。举个例子，调用一个发短信的接口，不仅仅是收信人电话号码和短信内容，还要包括很多业务含义的参数，例如发信人的姓名、组织、发信的系统、发信的原因、发信时和客户接触的渠道（客服渠道、网点渠道、网银渠道、自助终端等等）、发信时关联的产品，这些信息是可以用来计算成本、控制次数、避免重复骚扰客户；用户名、密码、验证码、发送时间等这是用作安全验证的；优先级、发送渠道等是用来做流量控制的；流水号、全局业务ID、请求ID、请求时间等等是用来做监控的。上述信息来自与每次发短信的上下文，在实际开发期间就要做很多的赋值、转换工作，将上下文的信息传递给服务，这种转换就像下图那样，典型的面多了加水，水多了加面。我们需要根据当前上下文和服务的特征，自动的进行一些适配，避免人工的重复性劳动。

（3）系统的联动问题。当一个业务事件产生时，有很多相关联的系统都会需要作出关联性反映，例如一个航班延误，就会涉及机票的改签、酒店的改期、接车服务的改期、会议安排的变更、日程计划的变更。一般我们会设计一个事件中心，为各个系统开发出监听的程序，当事件到来时判断上下文信息，决定产生的动作。如果事先没有设定的规则，就无法产生联动，我们期待更加自动化的建立这种联动关系，让计算机智能的产生动作而不仅仅通过人为设置。

类似问题还有很多，我们期待能够更加智能的集成。

需要集成的部分不只是软件本身，软件过程也是一个复杂的集成/协作工作

分而治之的软件需要通过集成方式整体交付，软件的生产过程也是一个多人、多组织协作的过程，也需要集成。把软件看成是一个产品，产品就有策划、研发、运营和退出各个阶段，每个阶段可能由不同的人或组织完成。软件的研发阶段就是一个一个项目的实施过程，包括立项、执行和完工。这样的过程组织起来，就是一条软件生产的流水线。从早期瀑布式的软件研发，到后来敏捷研发过程、CMM，到目前风头正劲的DevOps，都是在解决软件生产流水线不同阶段的协作问题，敏捷针对软件定义、设计、构建（开发）阶段的协作，持续集成是构建（开发）与测试阶段的协作，持续交付是从定义阶段到部署（交付）阶段的协作。

协作中面临的问题，就是集成的问题，我们可以想到很多，这里也举几个例子：

（1）需求、设计与构建（开发）的沟通问题。我们需要把需求/设计的知识图谱化、条目化，自动与开发工作做一定程度的适配，减少需求/设计到代码的转换工作；

（2）构建（开发）与测试的沟通问题。我们需要根据服务和数据特性以及积累的历史数据，自动产生测试用例和测试方法；

（3）运营的沟通问题。我们需要通过应用画像、资源画像等方式，服务与物理资源之间建立连接，快速定位问题，进行容量预测，实现更智能的运维。

在软件架构中应用人工智能的目标：通过增强智能方式实现软件系统与软件工程的智能连接

应对复杂集成的挑战，我们可以引入人工智能的思路，将人与软件、物体与软件之间、软件与软件之间、软件生产线各环节之间通过知识使能的方式集成起来，在传统完全依赖规则进行集成的方式基础上，采用新的集成方法：以上下文信息为输入，利用专家已有的知识，通过数据训练和强化学习的方式，让计算机能够理解集成的意图，成为我们的智能助手，帮助我们实现智能的连接，进而可以让计算机探索新的连接知识。这里，我把连接也分为三个层面：机械连接、基于知识连接、创造知识连接。

三、从智能连接入手探索

在软件架构中应用人工智能

从何处入手，探索人工智能在软件中的应用，是大家最关注的话题，这里我把普元在探索人工智能初期经历的几个案例，给大家做一个介绍。普元董事长刘亚东博士早年就从事神经网络的研究，他指出在目前并行计算等技术充分发展的今天，算法已经不是人工智能的瓶颈，应用人工智能需要有两个突破（1）找到人工智能应用的切入点（2）团队具备人工智能应用的思维。所以我们在应用人工智能的时候，不是成立一个专门的小组做研究，而是百花齐放的方式。了解普元的朋友会知道，普元的研发分为云计算&SOA、大数据、移动、工程效率与技术平台、产品支持中心几个团队，我们让每个团队从数据 连接方向上入手，各自探索人工智能在领域上的应用场景，通过找到切入点和初步实践，逐步建立团队的人工智能思维。其中云计算&SOA团队的方向是通过服务画像方式解决微服务的智能运维与智能匹配，大数据团队的方向是通过知识图谱实现数据自服务，移动团队的方向是UI的智能化开发，工程效率与技术平台团队的方向是深度学习在流程与智能制造的应用。由于篇幅有限，这里我把普元大数据团队和移动团队所做的工作做一个介绍。

案例一：基于知识图谱，实现数据的自服务能力

先简单介绍一下背景：大家经常会听到有人问我们有哪些数据，这些数据在哪里，如何获取数据的问题，能否建立一个平台，让我们象百度搜索一样，根据我们的知识（业务术语）找到相关的数据，提交申请，得到数据，这就是一个获取数据的自助服务。

以往数据在哪里往往通过人工梳理完成，我们希望能够自动化一些，为专家提供一个智能的助手，这里的工作分为三部分：

（1）建立知识图谱。人进行数据搜索是通过业务术语（知识）来搜索的，而知识之间是有相互联系的，例如水果和苹果是上下位关系（后者是前者的具体体现），搜索是除了要列出直接结果，还需要显示一些关联的知识，这就要建立知识图谱。简单说知识图谱就是概念、属性以及概念之间的关联关系， 这个关系可以手工建立，我们通过对政策、法规、需求、数据库comments、界面等多种来源，采用自然语言处理等方法，可以建立起部分的知识图谱，辅助专家的工作；

（2）梳理技术元数据。整理各个系统内部数据，以及数据之间的关系，形成数据地图。这里的难度是数据之间的关系，例如数据的血缘关系、影响度关系、关联关系、主数据关系等，这里我们采用字段特征的相关性、数据处理逻辑的词法/语法分析等手段，配合强化学习来完成，前面列举的查找外键示例，就是一部分；

（3）建立知识图谱与技术元数据之间的关系，这里就要通过分析界面/服务与代码之间的关联，建立起映射关系。最终效果就是，使用数据搜索，录入希望查找的业务术语，得到相关结果，查看样例数据，如果是需要的数据，提交使用申请，如果不是，继续根据相关知识进行数据探索。提供数据自服务能力，就是在应用的设计师、数据科学家或者业务分析师与数据之间建立起连接，我们的团队就是从连接的思路出发，找到了人工智能的切入点。实际上，数据自服务包含有找、获、用等众多环节，我这里说的是找的环节如何实现，这种找的方法，也不可能100%准确，还需要专家进行调整，以及通过强化学习等手段不断修正，可以看出，应用人工智能也是一个渐进完善的过程。

案例二：通过深度学习，实现移动UI的智能化开发

移动UI的智能化开发，是我们移动团队应用人工智能的第一个尝试，现在看来，就是在UI设计师与开发工程师之间建立连接。大家会发现，设计师的设计在变成代码实现时总会有偏差，即使一个像素的差异，也会影响界面的效果，以往我们采取不同业务模板的方式，建立一些规范对设计和开发做约束，后来移动团队觉得，可以用深度学习的方式做一些尝试，寻找不同的界面设计效果，首先通过数据标签方式确定页面的风格，再通过图像片段的方式学习和识别设计稿中的组件，最终经过多次的处理，变成一个树状的结构，把这个树状结构与代码进行映射，就产生了和设计图一致的代码。

这个案例中，基于图片的神经网络学习是一个关键技术，但是如果单纯使用这个技术，计算量会无法承受，所以我们将处理过程分成了几个阶段，每个阶段进行分类，每个阶段都可以配合强化学习的方式，由人工指定策略，指导计算机的学习，提高了工程化的能力（类似做法在深蓝对阵卡斯帕罗夫的时候就有应用，有一位特级大师会指导深蓝当前的策略，例如进攻还是防守，具体招数由深蓝决定）。

上述两个案例中，我们首先在各个领域中找到可能的切入点，针对不同场景使用了不同的方案，并不是都采用了深度学习/神经网络的方法。我们没有首先从Tensorflow等框架学起，而是在结构化、半结构化优先使用统计方法，非结构化数据再使用深度学习，是用业务驱动的方式逐步推进，有效的避免了“深度泛滥”。

转自EAWorld