软件开发是什么行业-工业互联网需要什么样的软件开发| DevOps 行业技巧

完整字数

5000

特点

阅读时间

11

分钟

DevOps是一个集开发Dev和运维Ops于一体的平台。 随着工业互联网的兴起，DevOps和微服务恰逢其时。 其重塑软件开发的能力正在引起广泛关注。

我们先从六组数据开始

随着工业APP的普及，企业应用成为新的热点。 那么一个企业需要多少“应用”呢？ 我们先从六组案例开始。

第一个数据显示，某银行拥有2万多个应用程序，其中约1万个基于J2EE，运行在IBM的中间件软件WAS系统（WebSphere Application Server）上。

第二个是电信行业的OEM制造商，其内部IT管理应用程序大约有2000个。

第三个是某钢铁集团企业。 其应用范围从研发到现场制造再到企业运营管理，其中包括工业互联网，应用程序约500个。

第四是某个车联网平台。 车联网平台已建成17个应用。 但2019年的新要求是根据功能点提出的，总共有700多个新功能点。 这些需求是压倒性的，根本没有时间来开发它们。 而这700多个功能点又有多少应用呢？ 客户也不能确定。

第五组数据，某制造企业的SRM（供应商关系管理系统），被拆分为四大功能模块。 这四个功能模块被拆分为47个微服务。

第六组数据来自一家汽车零部件制造企业。 第一代车联网有5个应用，总共分为38个微服务。 38个微服务开发的程序只能支持3万辆注册汽车。 一般来说，1:10的并发体验值意味着无法满足3000辆车同时并发的需求。 目前，国内车企的注册需求大多为数百万至1000万辆。 这意味着这个车联网平台刚刚发展起来，面临着新的转型压力。

有了以上六组数据，我们不禁要问：这里包含的申请是如何统计的？ 有的有2万，有的只有17，差别这么大吗？

这些数据背后的潜台词与软件架构有关。 将每个微服务称为应用程序并没有错； 也可以将大量应用程序称为应用程序。 像SAP的ERP这样大的系统包含如此多的子模块，可以称为应用程序。 如果你想把整个ERP拆分成财务管理、人事管理等应用，甚至继续把财务管理拆分成应用子模块软件开发是什么行业，都可以。 也许一个ERP可以拆分成100个应用程序，这也不是不可能。

银行有两万多家，制造业好像只有几十几百家，最大的也只有几千家。 为什么？ 因为银行的IT成熟度非常高，而且在制造业的应用场景非常复杂。 那么走向数字化的制造企业应该拥有多少应用程序呢？ 未来制造企业需要什么样的人员规模来支持IT？

这些话题都涉及到应用架构，以及工业软件的整个研发流程和研发体系。

大规模软件开发的挑战

软件开发和流程制造之间的相似性非常强。 它们都是一条装配线。 软件开发与软件技术架构密切相关。

相对成熟的软件开发，无论是在哪个行业，在大规模的软件开发过程中都会面临很多挑战。 比如很多客户要求自动化测试，但这意味着要使用很多运维工具。

灰度发布也是一个重要的概念，尤其是当今基于云技术的软件开发的重要需求。 在应用程序开发的整个生命周期中，需要进行功能测试和性能测试。 企业开发环境中的测试通常是功能测试； 压力测试，包括用户体验测试，一定要有一些真实的用户体验。 灰度发布使得测试工作可以按组、按区域、按功能分步进行，方便迭代。

在工业互联网应用开发中，不能一次性发布所有功能，否则对企业的影响太大。 通常在软件开发过程中，会分为阶段，比如选择特定的客户群体或者特定的功能，并在特定的时间点发布。

另一个重要概念是多云管理。 未来工业互联网的后台可能会有多个云，包括多个私有云、多个公有云以及传统非云环境中的一些数据和应用。 在软件开发过程中，需要考虑这些问题。 很多时候，各种应用软件和中间件软件有数百甚至数万种。 每个软件本身在编程过程中都有一个机制。 这个机制会吐出一些信息。 这些信息称为日志（LOG）。 。 例如数据库，IBM DB2和Oracle各自有不同的日志信息； 就PLM而言，SAP和西门子的日志不可能相同。 要分析整个软件的运行状态，全面了解其状态，就必须清楚各个软件的日志。 当软件数量达到一定程度时，手动处理就变得不可能了。 需要软件来自动分析这些日志信息，辅助运维人员进行运维工作。

这些是软件开发生命周期中遇到的众多挑战之一。 如果考虑更多的人员、组织架构等问题，那就变得更加复杂。

以上都是大规模软件开发的挑战。

软件技术架构的三大演变

软件技术架构在不断发展。 从单一应用到SOA架构再到现在的微服务架构。

图1：软件架构的演变

早年的软件开发都是基于单一架构+UI。 这种架构的特点是后台有一个Database，前面有一个用户界面UI，通过UI以某种形式展示后台Database的一些数据。 此时的软件架构层次比较简单，只有两层。 但单体架构的缺点也很明显。 其复杂度逐渐增加，部署速度越来越慢等等。 一个单一的应用系统，从操作系统，到上面的数据库、运行环境、一些支撑库，再到应用软件，一般需要两到三个月的时间来部署。 因此，大规模单体架构应用软件的部署变得越来越复杂，并且无法按需扩展。

关于可扩展性，以一家拥有 10 万人的公司为例。 电子邮件系统通常需要十几台、几百台甚至上千台X86机器在其背后运行作为服务器，但这些服务器在晚上基本上都是闲置的。 状态。 如何让这些设备更高效地运行？ 晚上能不能只留下十几二十台设备来保证一些基础服务的运行，然后大量的算力就会处于休眠状态。 等到上班了，再唤醒资源，逐步拉伸。 云架构的优势是显而易见的。 这种需求是单一架构无法满足的。 必须用更先进的技术来完成，这就是云架构。

图 2：SOA 架构

大约十年前，新的架构SOA被提出。 SOA架构：数据+用户界面+公共服务，这是面向服务的架构。 在数据库和用户界面之间添加了一堆公共服务，这些公共服务通过企业数据总线连接起来。 在制造业中，OPC UA标准系统可以连接所有工业产品和工业设备。 在软件架构中（即在数字世界中），它是一种服务，有多少个开放接口就可以有多少个服务。 所以在软件世界里，无论是设备还是软件服务，对用户来说没有区别。

SOA架构的主要特点是它松耦合了服务提供者和服务消费者之间的关系，大大提高了应用架构的灵活性。 但SOA架构不考虑服务规模。 小的只有几兆甚至几百千字节，大的有几千兆字节，甚至超过100G，都称为服务。 前面提到的单体架构中所谓的“扩展”问题又出现了。

架构还需要再完善，就是今天说的微服务架构。

微服务即将到来

微服务是一种全新的服务架构。 它是一种软件开发方法，涉及到很多概念。 几年前，互联网公司提出了一个叫SQUAD的概念，是一种伴随微服务架构的软件开发的人员组织形式。 通俗地说，小队就是分配一定职能、具有一定独立性的小团队。 这支队伍很像军队里的一个小队。 可以作为基本单位执行任务，班内也有管理制度。 这个概念在软件中其实也是一样的。 通常建议10-12人组成一个Squad，以一定的相对独立性发展软件开发是什么行业，然后相互安排组合。

最近提到的比较多的是Agile敏捷开发，对应的是瀑布风格。 这个概念并不新鲜。

瀑布式软件开发是一种传统的开发方式。 例如，供应商管理系统 SRM 应该是什么样子需要大量的研究和规范。 然后就被密封起来，不能再更改，开发团队就按照这个规范进行软件工程。 软件工程完成后，需要几个月的时间进行测试，测试完成后发布。 这个版本发布后会维护一年，甚至两年，甚至三年。 一个版本通常有一个周期，有的是五年表情包设计，有的是六年，但一般不超过8年。 这是典型的瀑布风格。 它像水一样从上流到下。 它是不可逆的，只能顺序推进。

图3：瀑布式开发

以这种方式开发的软件在推向市场时不容易适应快速变化。 后来出现了一种迭代开发方法，即敏捷开发。 整个研发周期发生了变化，开发的组织形式也发生了变化。

微服务开发是从敏捷开发方法演变而来的。 这里，现在出现了一个新词，称为CQRS（命令查询职责分离）。 中心思想是，所有的功能都分为两类：一类是Command类型，是一个大类；一类是Command类型，是一个大类。 另一种是Query类型，在后台分布式数据中查找需要的信息。

微服务开发要求软件架构设计必须满足CQRS等设计原则。 每个微服务可以独立运行，也可以独立编排。 就像导演一样，每个演员都演好自己的角色，导演很好地安排这些角色，演绎出一个精彩的故事。 系统就像一部戏剧，由无数的微服务组成，以提供更完整的服务能力。 这个系统可以就是我们原来讲的应用软件，一个功能丰富的应用软件。

一个功能点可能是一个微服务，但也可能需要调用多个微服务来完成组合。 这就是微服务的思想。

微服务大小和容器

在微服务架构中，微服务的大小虽然没有固定的标准值，但一般在几十兆到100M以内。 如果拆分太小，微服务治理的复杂度会增加； 如果太大，就违背了微服务灵活扩展资源占用的初衷，并且难以隔离问题。

微服务的部署往往是部署在那里的可执行程序（镜像）。 微服务启动后，会被调入容器（运行环境）中，当然会占用计算资源，比如存储、网络和通信、CPU资源。 使用后，这些资源将被释放回来。

那么什么是容器呢？ 从技术上讲，它是容器中运行程序所涉及的指令的解释器。 考虑一个共享办公室的类比。 共享办公室提供办公环境。 所有办公室不能为100平方米； 或者都可以是1000平方米。 需要不同大小的房间来容纳不同规模的公司。 但每个办公室都必须有一些基础设施，比如水、电、煤气或者WiFi等。一个公司进来，收拾行李搬进去，它需要的所有服务都有。 用多少付多少，用完可以随时离开，办公空间被循环利用。 这个环境可以比作微服务所需的容器。

开发运维一体化流程DevOps

“DevOps”集成流程已成为当前软件交付最重要的形式。 这是一条装配线。

图 4：DevOps 流程

首先，程序员编写程序。

二是源代码管理。 在一些成熟的软件开发组织中，源代码管理非常严格。

下一步是构建。 做OT的人可能对这个词有点陌生。 对于IT人员来说，这个词并不陌生。 是指将软件的源代码编译成可执行代码，例如exe。

那么打包的过程就称为分页。 编译后的软件除了源代码之外，还包括它的一些依赖程序。 具有单体架构的应用程序必须封装在一个大包中； 在云中，包要小得多。

包打包完成后，进行部署。 部署完成后，开始测试。

测试将包括功能测试和性能测试。 通常功能测试难度比较小，在测试环境中进行测试； 但在进行性能测试时，必须有大量的实际数据。 无论是模拟还是模拟数据都不能最终解释问题。 需要实际数据和压力。 测试更有说服力。 此外，用户体验还需要目标用户的参与，体验的质量更加真实。

测试完成后，开始灰度发布。 灰度发布后，发现问题，修改程序，进入迭代过程。 迭代完成后，将进行大规模、全面部署。 就这样进入生产线了。

这是一个完整的生命周期。

那么，这个流程的人员如何配备，比如架构师、测试工程师、产品经理或者Offering Manager等。互联网公司OM的身家普遍都很高。 因为OM的责任会比过去的项目经理更大。 接下来将进行运维工作。 软件系统投入使用后卡通人物，如何管理？ 我们借用了OSS的一个概念，称为运营和支持服务。

整个管道形成了一个完整的DevOps概念。

图 5：DevOps 需要大量工具

目前，许多公司听起来都拥有 DevOps，但它们的成熟度水平各不相同。 运维体系、工具、流程有所欠缺。 很多大型企业拥有数千名IT人员，但运维体系不够清晰，甚至根本没有体系。 文化、组织配套设施与之完全不同步。 只有一些工具，仅此而已。

图 6：持续 DevOps

进一步探究，就有了连续性的概念。 这就是持续 DevOps。 连续性，包括持续集成、持续部署、持续测试等，这是所有云平台都需要具备的能力。

显然 DevOps 已经超越了开发过程。 它是一个工具集，但更多的是一种组织和软件文化。 这是工业互联网超越技术发展过程中很容易避免的一大陷阱。

概括

DevOps是一个漫长的旅程，但它为工业互联网的软件开发满足制造业的需求提供了良好的路径。 微服务架构也正在成为一种非常流行的工业软件开发方法。 了解微服务和DevOps架构的开发方法，将使工业应用能够快速形成服务能力并不断迭代更新，从而以强大的IT支撑和服务能力支撑更多的OT应用，让工业互联网更好地落地。

（感谢南山工业学院各位同事的协助，特别感谢新华三都李政的整理。）

新书推荐

林学平、赵敏、宁振波、黄长霞等主编的《智能制造术语解读》一书精选了智能制造领域的62个术语，通过“整理对象和标准，研究链接与理解智能”，以简单易懂的方式进行科普解读。 该书已在京东、亚马逊等各大网店上架。 欢迎关注。