在前面一篇谈数字化转型的趋势文章中，我曾经谈到过当前企业数字化转型，特别是大型集团性企业，有一定IT建设技术积累的企业，在数字化转型和IT平台和应用构建过程中，有一个关键转变点就是自主可控。
很多大集团企业当前主流趋势都变成了自建IT团队，进行相应的IT系统开发和后续运维，而不是类似传统模式下去选择商业套件产品。对于ERP套装软件，短期要做到自主研发不现实，但是除了ERP软件，大部分上层应用软件企业已经具备自主研发能力。
也就是ERP应用下沉为企业的后台能力，而基于ERP上层的各类应用变成了前台，同时由企业IT团队自己开发，并自己进行后续实施和运维管控。
（图片来自网络侵删）自己组建团队从头开发内部应用，看上去并不省钱，前期投入成本往往比构建成熟的商业套件花费更大。但是带来两个关键好处，其一就是敏捷响应业务需求的能力；其二是真正做到自主可控，合作IT支撑能力掌控在自己手上，而不是被开发商绑架。
所以今天准备再来讨论下数字化转型过程中IT建设自主可控的话题。
自主可控本身是一个大命题，当前谈的开源，国产替代，鲲鹏云生态，信创，核高基，鸿蒙等都可以划入到自主可控的范畴。今天谈的自主可控则重点谈IT应用建设中的软硬件方面的自主可控。
从早期的去IOE谈起
如果回到14,15年左右，当时谈得最多的不是自主可控，而是由互联网发起逐步也延伸到B端企业信息化建设的去IOE。去IOE简单来说就是要去掉昂贵的IBM小型机，Oracle数据库，EMC的集中化存储，而采用相应的X86服务器，开源中间件进行替代。
大家要注意到去IOE当前本质已经是变化为解决数据库层面的问题，对于应用服务器和中间件，采用X86服务器和负载均衡，集群技术本身已经不存在太大的问题。包括其可靠性，可扩展性和性能等。当前我们看到的很多应用本身也是应用服务器层基本全部X86+虚拟化，而对于数据库往往还在使用小型机和集中存储。
现在的高性能的X86服务器性能已经赶上了3，4年前的中端小型机性能。比如现在的6到8C，8核高配的X86服务器性能能够达到80-100万TPMC，而3年前的中端小型机性能也就60万TPMC的样子。对于小型机的替代大家最关心的问题仍然是高可用性，小型机基本可以达到5个9的高可用性，而现在随着类似至强7500等X86服务器引入了大量在小型机中才使用到的RAS技术，基本达到4个9是没有太大问题的。
还有就是小型机的纵向扩展能力相当强，比如CPU可以最多扩展到24个，而对于X86服务器则是希望通过横向扩展来应对小型机的纵向扩展能力。而横向扩展自然带来的一个问题就是分布式的问题。
对于数据库层面，拿MySQL数据库来和Oracle数据库做一个比较，当前第三方的评测是在相同的硬件配置条件下两个数据库的性能和Benchmark数据库相当。而实际上对于数据库层面我们更加关心的还是在海量数据下的复杂事务处理能力。如果对于存储大表数据都在千万行级别一下，可以说两个数据库可能不会出现太明显的差距。而如果对于大于千万或上亿数据的海量数据OLTP处理上，Oracle估计还是具备有明显的优势。而对于这一个问题的解决，根据互联网企业的经验，仍然是通过数据库的水平拆分和垂直拆分来解决这个问题。
类似EMC提供的集中存储是另外一个重要的话题，可以看到在使用集中存储的时候，我们很容易去实现类似Oracle的RAC集群，同时本身集中SAN,NAS存储也具备更高的存储高可用性和高可靠性。类似互联网企业淘宝也曾经谈到过，在采用廉价的本地磁盘存储后，由于大量的IO磁盘读写也经常出现硬盘挂掉的情况。虽然这些可以通过RAID技术来避免单独故障，但是对于存储的高可靠性确实本地存储赶不上集中存储。
在云数据中心建设中，你会看到采用类似Ceph来实现一个分布式的共享存储，或者采用NFS来提供共享存储，都是一种对传统EMC存储的替代方案。但是不得不说，这些替代方案在性能和稳定性上比FC SAN实现还是有较大差距。
由于在去小型机，Oracle数据库和集中存储情况下，将直接转换为数据库层的构建成为一个share nothing的分布式数据库集群。而现在的MPP+Share nothing的New SQL数据库，类似Greenpulm，Vertica，Hive等更多的都是解决OLAP层面的问题。而对于去IOE首先需要解决的是联机事务处理层面的事情。
最近几年出来一个新的开源MPP数据库ClickHouse，当前也已经相当成熟并不断在真实场景中得到应用，感兴趣的也可以关注。
那么对于Share nothing的分布式数据库，当前也有类似Mysql Cluster技术来支撑，但是这种分布式数据库虽然做到了高可靠性，但是由于需要支撑CUD操作，导致这种集群很难达到满足实际应用需求的存储容量和业务高性能。在实际的业务应用场景下，除了少量的类似MDM主数据场景比较适合采用外，真正的核心的大量业务操作和逻辑处理场景往往并不适合。
基于这种情况，当前最常用的技术是对数据库进行水平拆分和垂直拆分，但是这种拆分我们希望的是对应用层透明，因此在数据库上面引入了一个核心的DaaS服务层。但是当前的DaaS服务层很难做到数据库的完全透明，同时对于上层的应用构建造成一定的约束。包括有些跨库的Sql语句，类似跨库聚合Group By等的语句不支持，这些都需要应用层自己去解决。
在跨库后带来的一个重要问题就是分布式事务的问题，对于DaaS来说可以解决部分分布式事务的问题，但是需要采用严格的XA两阶段提交来解决分布式事务，本身的高可靠性和一致性仍然需要进一步进行验证。而对于应用，仍然需要应用去解决一些分布式事务的问题，即通过事务补偿，BASE方法等去解决分布式事务的问题，这些本质上都是削弱了对高一致性的支持，这也是CAP定量经常说的，在一个分布式的系统中很难真正做到三者全部满足。在满足高可用性和分区容错性的基础上，往往需要牺牲一定的高一致性。
由于采用数据库拆分和DaaS层，对于应用层的应用构建将带来比较大的变化，特别是很多原来数据库没有拆分的时候一个SQL就搞定的问题，一个通过数据库层事务就能解决的问题，都会变成了分布式事务问题，或者多次调用服务操作才能够解决的问题。这往往才是说得去IOE的一个关键。
自主可控，国产化和开源
注意前面谈到的去IOE运动，最开始的考虑并不是自主可控，而是降低整个IT硬件设施和基础中间件的成本投入。而当前谈的自主客户，则更多是从自主知识产权，国产化等方面再考虑。
举个简单的例子你如果采购类似人大金仓，达梦数据库，整个成本并不是一定比采用类似Oracle，SqlServer数据库便宜多少。但是好处就是符合当前国家的自主可控，国产化替代和新创发展趋势。
那么开源是否也算自主可控？
实际上当前很多国内的国产化软件，本身底层也是基于开源软件进行的二次开发，采用开源软件本身也是实现自主可控的一个关键。企业采用各类开源软件，并不是开发一个新产品用于产品销售，从当前的开源软件授权协议各方面来说完全可行。
开源带来的一个好处就是至少源代码可见可控掌控。
但是当前开源软件本身也出现免费版和社区企业版的分离，对于社区版或企业版本同样需要付费，而且有些核心技术模块代码本身也没有开源，而且开源软件你购买后续的技术支撑服务同样需要付费。
在很多年前我们实施SOA项目就为客户做过比较，当前可以选择Oracle SOA产品套件和Mule开源ESB的商业服务版本。由于Mule本身是按年度收技术服务订阅费用，实际核算下来即使按使用3到5年，那么Mule实际投入成本都超过Oracle产品套件。
所以开源本身也不一定节约成本，但是开源带来的关键好处是自主可控。
简单总结下就是对于国产化各类基础软件本身并不开源，但是符合国家大力发展自主软件政策和最新的信创发展政策，从国家层面是自主可控；对于国外的一些开源软件，本身可以开放源代码，降低被厂商绑架的风险，但是可能后续的技术服务也不便宜。
当前就甲方企业来说。如果你是国企或政府行业，对各种安全性要求都更高，更多的方式都是直接购买国产化基础软件。而对于民营企业来说，当前购买国产化软件的很少，更多的还是采用各种开源软件，类似Mysql数据库，Tomcat中间件等，这些也都是很成熟的技术中间件并得到了大面积应用和验证。
在前面我们谈到了大的集团性企业更多的思路是自建IT开发团队，自建进行IT应用软件的开发和后续管控运维。当前还有一个思路就是仍然是公开招标，但是要求完全按自己的技术规范进行定制开发，并最终交付源代码。
这个技术规范实际已经制定了选择的数据库和中间件类型，开发框架和技术，技术标准要求等各种内容，所有入围的厂家都需要按照标准的技术规范，开发框架和环境进行应用软件的开发，这属于定制化开发范畴，而不是简单的提供一个你已有的成熟软件。
注意特别是在微服务架构后，原来的一个单体应用往往已经拆分为多个微服务模块，甲方企业完全可以将一个应用拆分后分包给多个供应商定制开发，那么开发商之间本身就成为一个相互备份和可替代关系，而不是被单一供应商完全捆绑。
最近从招投标情况来这种情况逐渐变多，就是集团企业更多的是招标软件开发外包的大框架协议，而外包需求，外部技术规范，开发框架标准等甲方都会在发布的技术规范中说明清楚。所有入围的厂家遵循相同的开发标准规范，技术框架体系进行开发，而且最终提供开发完成的源代码，那么甲方也更加容易做到自主可控。
在这里必须打个小广告。
一个甲方招标了很多个开发商进行按自己的需求进行定制开发，那么如何加强对开发商整个开发生命周期的全过程管控和质量检查，确保开发商最终交付的产品本身满足需求，同时产品本身甲方能够接手运维。这里面就是涉及到需要对整个开发过程，CI/CD持续集成和持续交付，测试和质量管理全过程管控。而这也正是我们DevOps平台提供的关键价值。
从自主可控到云原生
在前面谈数字化转型的时候已经谈到，当前整个IT发展趋势是云原生。原来是IT基础设施建设从自己构建到直接使用云服务商提供的云资源池。而到了云原生阶段后，整个抽象进一步上移，从资源的使用变化到服务的使用。
举个例子来说，你原来构建应用需要考虑选择哪个数据库，然后自己安装配置，后续运维这个数据库。而现在你可能使用的是云服务商提供的数据库服务，你不用再去关心数据库的安装和运维。你只需要关心应用层的软件开发和功能实现。
底层技术资源提供+底层技术服务提供都全部云化。
那么在这个时候又如何去做自主可控？
简单来说你需要考虑的是应用层的软件开发，比如你使用当前主流的类似Springcloud微服务开发框架去进行应用开发，最终开发完成后将其持续集成和交付到云环境即可。这个应用本身的开发源代码还是在你手里面，你能够做到自主可控。
但是这个时候实际引入一个新问题。
各个云平台服务商都推出了自己的各类PaaS层技术服务能力，包括了数据库，缓存，消息中间件等各种服务能力，也包括了自己的DevOps研发效能管理平台等。其核心目的还是希望能够将云服务延伸到企业需求开发过程管理中，做到深度绑定。
那么从企业角度你需要思考的问题就很简单，即不能被单个云服务商完全绑架，今天你的应用托管在阿里云，明天也能够快速平滑的迁移到华为云，只有这样你才能够做到完全的自主可控。
而要做到这个，又涉及到一个核心能力就是你需要去构建一个混合云的管理平台，你最终开发的应用能够同时向不同的云环境交付，这个混合云管理平台需要完成对多个公有云服务商服务能力的适配。而这个也是我们自己的DevOps平台的一个优点，感兴趣的可以发翻看我前面发布过的文章进行详细了解。
