工业互联网需要什么样的软件开发.docx

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 台汽车同时并发的需求。而现在国内的大部分车企 目标，都是在几百万到一千万台车的注册需求。这意味着，这个车联网平台，刚刚开发出来， 就面临全新的改造压力。 有了上面六组数据，我们不禁要问：这里面的应用，都是怎么数的。有的是2 万个， 有的只有区区 17 个，差别如此之大 这些数据背后的潜台词，都是跟软件架构有关系。如果把一个一个的微服务就叫一个应 用，那不能说错;要把一个大的一个应用的集合叫一个应用，也是可以的。像 SAP 的 ERP 这样大的系统里面，包括了那么多的子模块，叫一个应用也可以。如果要把整个ERP 把它拆成比如说财务管理、人事管理等应用，甚至财务管理继续拆下去到应用子模块，都可以。也许一个 ERP 可能会分拆成 100 个应用，不是不可能的。 银行是 2 万多个，制造业好像才几十、几百，最多的一家也就数千个。为什么因为银行的 IT 成熟度非常高，而制造业的应用场景则非常复杂系。那么走向数字化的制造企业， 到底应该有多少个应用未来制造企业里面的IT 到底需要什么样的人员规模来支撑 这些话题，都涉及到应用架构，以及工业软件整个研发流程和研发体系问题。 大规模软件开发的挑战 软件开发和流程制造的类比性非常大，它们都是一个流水线。而软件开发，则与软件技术架构密切相关。 比较成熟的软件开发，不管是哪个行业，大规模软件开发的过程都会面临许多许多的挑战。例如，很多客户提出自动化测试的需求，但这就意味着好多运维工具的使用。 灰度发布，也是一个重要的概念，尤其在当今基于云技术软件开发的一个重要需求。一 个应用开发的完整生命周期过程中，需要进行功能测试和性能测试。在企业开发环境里测试， 通常都是功能性测试;进行压力测试包括用户体验测试，那就必须要有一些用户真实的体验。灰度发布则是使得测试工作以分群的、分区域的、分功能的阶梯式的开展，以便于迭代。 工业互联网应用开发，不能把所用功能一口气一下子全部发布出去，否则会对企业冲击会过大。通常在软件开发过程之中，它会分阶段，比如选特定一些客户群，或者特定一些功能，在一些特定的时间点做一些发布。 另外一个重要的概念是多云管理。将来工业互联网有可能会在后台会有多个云，包括多 个私有云、多个公有云，还有一些数据和应用是传统非云的环境里。在软件开发过程中，这 些问题都需要兼顾。许多场合下，各种应用软件以及中间件软件有数百甚至上万个，每一个 软件本身在编程过程之中都会有一个机制，这个机制会吐出一些信息来，这个信息就叫做日 志(LOG)。如数据库，IBM DB2 与 Oracel 各自有不同的日志信息;就 PLM 而言，SAP 和西门子的日志也不可能一样。要对整个软件的运行状况进行分析，综合了解它的状态的时候， 就必须对各个软件的日志要很清楚。当软件数量大到一定的程度时，就不可能做到人工处理 了，必须要有软件，对这些日志信息自动进行分析，辅助运维人员的运维工作。 这些都是在软件开发生命周期中遇到的诸多挑战。如果将更多的包括人员、组织架构等问题考虑进去，则更为复杂。 以上都是大规模软件开发的挑战。 软件技术架构的三次大演进 软件技术架构在不断进化。从单体应用到SOA 架构，再到当下的微服务架构。 早年的软件开发都是单体架构 monothetic+UI。这个架构特点