从六组数据说起
随着工业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架构，再到当下的微服务架构。
图1:软件架构的进化
早年的软件开发都是单体架构monothetic+UI。这个架构特点是后台有一个Database，前面有一个用户界面UI，把后台的Database的一些数据通过UI以某种形式展现。此时，软件架构层次比较简单，它只有两层。但单体架构的缺点很显然，它的复杂性逐步提高，部署的速度越来越慢，等等。一个单体应用系统，从操作系统，到上面的数据库、运行时环境，再有一些配套的库，再到应用软件，一般情况都得要两三个月才能部署。所以大型单体架构的应用软件的部署已经变得越来越复杂，而且无法按需伸缩。
关于伸缩性，举个例子，拿一个十万人企业为例，电子邮件系统通常都会要十几或几百甚至上千台的X86的机器作为服务器在后面跑，但是夜间这些服务器基本都属于空转状态。如何让这些设备更加有效的运行，能否晚上只留十几台二十台保证一些基本的服务在运行，然后大量的计算能力全部都是休眠状态。等到上班之后，再把资源唤醒，逐步伸展出去。云架构的优势显而易见了。这种需求，单体架构是无法做到的，它必须是用一个更先进的技术来做就是云架构。
图2:SOA架构
大概十年前，新的架构SOA被提出来。SOA架构:数据+用户界面+公共服务，这是面向服务的架构。在数据库和用户界面之间加了一堆公共的服务，把这种公共的服务用企业数据总线串起来。在制造业中，OPC UA标准体系，可把所有工业产品、工业装备连接进来。在软件体系架构里面（即数字世界里）它就是一个服务，开放出来的接口有多少个就可以有多少个服务。所以在软件世界里，无论一个设备还是一个软件服务，对用户而言，没有区别。
SOA架构主要特点就是松耦合了服务的提供者和服务的消费者之间的关联，应用架构的灵活性大大提升了。但是SOA架构没有考虑服务大小。小的只有几兆甚至几百K，大的有几个G的，甚至100G以上，也都叫做服务。前面单体架构里面谈到所谓“伸缩”问题，又出现了。
架构又需要改进，这就是今天提到的微服务架构。
微服务来了
微服务，是一种全新的服务架构。它是软件开发的一种方法，这里面会涉及到很多的概念。几年前互联网公司提出一个叫SQUAD概念，它是伴随着微服务架构的软件开发的一种人员组织形式。通俗地讲，Squad就是赋予一定职能的小分队，具有一定的独立性。这个小组其很像军队的一个班，可以作为基本单位去执行任务，而且squad里也有管理制度。这个概念其实到了软件里面也是一样，通常会建议10-12个人组成一个Squad，以一定的相对独立性来开发，然后相互之间再进行编排、组合。
最近提的多反而是Agile敏捷开发，与瀑布式相对应。这个概念不新鲜。
瀑布式软件开发是传统的开发方式。举个例子，供应商管理系统SRM，应该长成什么样子，需要做大量的调研，形成规格书。然后封存起来不能再改了，开发团队按照这个规格书再进行软件工程。软件工程之后，再需要几个月时间进行测试，测试完了进行发布，发布完了之后，这个版本就要维持一年，甚至两年，甚至三年。一个版本通常它会有一个周期，有的是五年，有的六年，但一般不会超过8年。这就是一个典型的叫瀑布式的，它就像水似的从上往下倒，是不可逆的，只能顺序推进。
图3:瀑布式开发
这种方式开发出来的软件推向市场，不太容易适应快速变化。后来出现了一个迭代式开发方式，也就是敏捷开发，整个研发周期发生变化，开发的组织形式也发生变化。
微服务开发正是从敏捷开发的方式演化而来。这里，现在又出了一个新的词，叫CQRS（Command Query Responsibilities Segaration）。中心思想是，所有的功能，分成两类：一类是发号施令的Command型，这是一个大类；一类是Query查询型的，到后台的分布式数据里去把所需要的信息查找出来。
微服务开发要求软件架构设计时，要满足CQRS这样的设计原则。每个微服务都可以独立运行，可以独立编排。就像导演一样，每个演员演好自己的角色，导演把这些角色编排好，演绎出一个精彩的故事。一个系统就像是一个剧，有众多的微服务组成，提供更加完整的服务能力。这个系统可以就是我们原来讲到的一个应用软件，一个具有丰富功能应用软件。
一个功能点可能就是一个微服务，但也可能需要调用几个微服务来组合完成。这就是微服务的理念。
微服务的大小与容器
在微服务架构中，一个微服务的大小虽然没有一个固定的标准值，，但一般在几十兆到100M以内。分拆得太小了，微服务的治理的复杂度加大；太大了，违背微服务的对资源占用的灵活伸缩初衷，也不便于问题隔离。
微服务的部署，往往就是一个可执行程序（image）部署在那里。启动时，该微服务会调入容器（一个运行环境）中，当然就会占用计算资源，如存储、网络和通讯、CPU资源。使用完毕后，这些资源会被释放回去。
那么容器又是什么？技术上讲，是给容器里的程序运行时涉及到的指令的解释器。拿一个共享办公室来类比。共享办公室提供一个办公环境，所有的办公室既不能一概都是100平方米；或者一概都是1000平方米，需要有不同大小的房间以满足不同体量的公司进驻办公。但每间办公室必须有一些基础，如水、电、气或者WiFi，等等。一个公司进来，拎包入住，需要的服务一应俱全。用多长一段时间付多少钱，用完了可以随时走人，办公空间回收。这个环境，就可以类比成微服务所需要的容器。
开发运维一体化流程DevOps
“开发运维DevOps”一体化流程，已经成为当前软件交付最重要的一种形式。它是一个流水线。
图4:DevOps的流程
首先是程序员编写程序。
其次是源代码的管理。在一些成熟的软件开发组织里，对源码的管理是非常的严格的。
下一步是build，对做OT的人可能对这个术语有点陌生，对IT人员，这个术语就耳熟能详了，就是把软件的源代码要把它编成一个可执行代码，如exe。
然后打包这个过程叫pagage。除了源代码编译之后的软件本身，还包括它的一些依赖程序。单体架构的应用是一定需要打一个很大的包；而在云里，打包就小很多。
打完包之后再去部署deploy，部署完了就开始测试.
测试会有功能测试和性能测试。通常功能测试的难度会相对小一点，在测试环境里面测试;但是要进行性能测试的时候，必须有大量实际数据，仿真的、模拟的数据都没有不能最终说明问题，必须要有实际数据，压力测试才更加令人信服。还有用户体验也需要目标用户的参与，体验好坏才更加现实。
测试完了之后开始进行灰度发布。灰度发布之后发现问题，再修改程序，进入迭代过程，迭代完了之后才会进行大规模、全面的部署。那就是上生产线了。
这是一个完整的生命周期。
那么，这个过程之中，人员怎么配备，比如说有架构师，有测试工程师，产品经理或者叫Offering Manager，等等。互联网公司OM的身价一般都非常高。因为OM的责任会比过去的项目经理责任要大。后续还有运维工作。软件系统投入使用以后，怎么进行管理？我们借用一个概念OSS，叫Operation & support services。
整个管道pipeline，形成一个完整的概念DevOps。
图5:DevOps需要大量的工具
目前,很多企业听上去都有DevOps，但成熟度参差不齐。运维体系、工具、流程有些缺乏。很多大型企业，IT人员规模达到好几千人，但运维体系不够清晰，甚至干脆就缺乏体系。文化和组织配套完全跟不上，光有几个工具，仅此而已。
图6:Continuous DevOps
进一步探究，就是持续性的概念。也就是Continuous DevOps。持续性，包括持续集成、持续部署、持续测试等。这是所有云平台都需要具备的能力。
显然Devops，已经超越了开发流程。它是工具集，但它更是一种组织，是一种软件文化。这是工业互联网的开发过程中，技术之外容易避不开的大坑。
小结
DevOps是一个漫长的征程，但它为工业互联网满足制造业需求的软件开发提供了很好的路径。而微服务架构也正在成为一种非常流行的工业软件开发方法。理解微服务和DevOps架构的开发方式，会使得工业应用能够快速形成服务能力，不断迭代更新，从而以IT强大支撑和服务能力，支持更多的OT应用，使得工业互联网能够更好落地。