当今技术快速发展的时代，任何技术的秘密并不能保存太久，相比之下，真正有价值的是实现技术的人。
要点速览
1. To C和To B在二十年前并没有本质差别，然而放眼当今的公司，具备技术储备的公司大都集中在To C。这里边最重要的原因在于To C是强运营的公司，为了支撑自己复杂的运营体系，而倒逼自身团队开发出系列满足自身需要的产品。
2. 当企业主动具备运营意识，能够提出自身的需求，那么才能从算法中获益，而相当多的企业，对于数据产品其实没有任何sense，在他们眼中数据产品提供者跟普通的外包公司没有任何差别，这就相当于被动的把数字化运营能力交给第三方公司，这样的企业实施大数据和人工智能战略，是很难走向成功的。
3. 绝大多数企业服务提供商通常依赖IaaS来提供核心中台能力，比如依赖阿里云的RDS服务，依赖腾讯云的CMQ队列服务等等。然而，我们却能够提供独立于任何IaaS之外的高可用架构。
近日，深见网络科技负责人张颖峰做客「火星财经创始学习群」，做了主题为“iABC—助力企业升级的思考和实践”的分享，同时与轮值群主蔡栋、联合群主陶欣进行了深度对话。
张颖峰表示，近2年To B的创业也算是赶上了风口，有说法是美国IT行业To B和To C比例接近1:1，中国则是1:20，那么有理由相信中国的To B行业会出现更多的机会。
然而事实并没有那么乐观， To B行业是伴随整个全产业的演进而进化的，换句话说，中国和美国没有可比性。
他认为，国内ToB难做的原因是，缺乏标准化产品；企业历史负担重，项目实施成本高；技术储备不足导致同质化严重，项目实施趋向于堆人力；企业自身原因。
以下为张颖峰分享内容，由火星财经（ID：hxcj24h）整理：
非常感谢火星财经和主持人，让我有机会在这里能够分享我们在如何帮助企业转型升级过程中，亦即科技公司的To B之路的思考和实践。
To B难做的原因
1. 缺乏标准化产品
2. 企业历史负担重，项目实施成本高
3. 技术储备不足导致同质化严重，项目实施趋向于堆人力
例如，服务人数多了，就要面对高并发，高伸缩，高可用的挑战，简单的堆人堆机器并不能解决问题，而此前这类挑战是由专业的国外技术提供商解决，只是这些提供商也并没有在低成本和高服务质量之间取得平衡，甚至针对部分场景则压根没有解决方案。
4. 企业自身原因
并不是所有企业都能够以最优化手段配置自身运营，或者说绝大多数都做不到这点。
企业对于IT信息化的需求，可以来自四个层面，以该图为例说明。
第一个层面是基于Web的应用逻辑，传统需求通常来自于这里，因为是最贴近业务的部分，也是客户最容易见到的，俗称功能性需求。
第二个层面是高可用高伸缩基础架构，俗称非功能性需求，更多地体现在中台或者PaaS层面的技术建设。
国内企业真正重视技术建设，可以以阿里云为代表。最近朋友圈有一篇文章一直在刷屏，叫《阿里云的这群疯子》。实际上该文在煽情的同时，并没有准确道明阿里云成功的全部关键要素。阿里云是伴随着国内公有云市场逐渐出现而壮大的。文中所提到的阿里云投入巨大成本建设的若干组件，更多是满足阿里内部需求。阿里云的这群疯子，其实是见证了新一代中国系统程序员的成长过程。
在十年前，中国人对系统软件是天生不自信的，Google的三驾马车论文虽然已经出来了7，8年，但如何把它们变成可以工作的系统对于广大码农来说仍然是黑科技一般的存在。
因此阿里在中国系统程序员还没成长起来的时刻，敢于投入力量去做一件不知道后果的事情，是非常令人尊重的。时至今日，伴随着开源运动大兴，乃至Google等公司让分布式系统技术不断地普及化，新一代中国程序员整体信心提升非常明显，往往很年轻的工程师就可以轻描淡写地说公司业务需求，所以就做了一个分布式系统。
行业内完全技术驱动的创业公司也开始浮现例如PingCAP等，都做出了令人尊重的工作。这些都不断在证明中国本土基础架构工程师水准的提升。
另一方面，伴随着公有云业务的发展和互联网技术的普及，企业在迁移到云的过程中呈现出几个关键需求：低成本、可伸缩、高可用。
这两个层面的变化导致了一个逐渐明显的趋势，就是传统以网站为核心的SaaS公司将开始倒计时，新一轮技术架构轮回将逐步开始。
第三个层面来自大数据和人工智能，这方面的需求在近5年来上升迅速，出发点的一个主要方面在于企业提升自身数字化运营能力的需求。
例如一些步伐较快的企业已经逐步让自己业务的运营走上了数字化的道路，因此进一步从数据中获得洞察就是自然而然。
只不过，在获取数据洞察这个过程中，不同企业自身对于“运营”能力的看重基本上决定了大数据/AI项目是否能够成功实施。
这一点其实跟互联网公司类似，大数据/AI最早在互联网公司广泛展开，而互联网公司正是从研发=>运维=>运营一条龙走下来的体系，它们最清楚自身的需求并有能力实现。因此针对这个层面的To B软件技术提供商，其实应当对客户有所选择，否则将落入一味的人力外包中苦不堪言。
大数据和人工智能需求产生的另一个因素则是被“忽悠”的结果。
对AI的焦虑是这两年企业的主旋律之一，然而真正接触下来，发现AI又远远达不到所需的要求，因此忽悠的最终，其实还是要企业来真正看到自身能够从中获得的收益。
AI近两年的泡沫之一，就是人才供给的巨大缺口导致的人才溢价，很多只会做论文工作的研究员也进入公司，他们固然能够对算法提供一些metric层面的提升，但是对AI的工程化落地毫无概念，这就很容易导致AI落地困难，以及进一步增加企业的负担。
企业级技术区块链
近两年又出现了以去中心为卖点的区块链，关于这点争议一直比较多，因为从技术上来说，尤其是企业级技术来说，并没有什么是非区块链不可的。
但是由于这个概念太广泛和深入人心，以至于很多人都认为它是银弹，正因为如此，那么在解决企业的某些需求方面，它就是最佳方案。
这个观点有些拗口，区块链不是万能的，但大家都相信它是万能的，那么在某些时候，它就是最佳方案——只是，作为严谨的技术从业人员来说，需要明确它的技术边界，而不是停留在概念忽悠上。
深见网络科技，就是一家专注于后面3点的企业级应用解决方案提供商。
我们的愿景，在于让企业从近10年中国的技术发展中获利，来真正降低自己的运营开销，并且提升自己的业务规模，既所谓的开源和节流。
iABC战略
我们的强项在于架构和算法两方面并重，因此可以针对任何复杂场景提供最优的设计架构。这表现我们核心团队具备对核心PaaS中台产品任何组件的原创级解决能力。这是一个PaaS，或者用现在一些流行的话来说"中台"的核心组件图。
这个图中，我们曾经打算，以及正在对其中的每个building block，做一些深入的工作。
举例来说，微服务已经是企业级应用的标配方案之一，然而我们更加关注的是进一步的微服务体系架构下长活事务的编排和异常处理，使得支付等金融级核心业务能够让用户轻松应对。
绝大多数企业服务提供商通常依赖IaaS来提供核心中台能力，比如依赖阿里云的RDS服务，依赖腾讯云的CMQ队列服务等等。
然而我们却能够提供独立于任何IaaS之外的高可用架构，例如真正高可用不脑裂的MySQL集群，弹性可自动Rebalance的分布式NoSQL存储，分布式强一致的事务性消息队列等等。
而且我们可以开发出任何可以跟IaaS提供商相提并论的中台核心组件，这就使得我们作为一个独立的企业级服务提供商，能够灵活的选取不同的云策略，为企业提供更加便捷和灵活的服务。
毕竟，IaaS本身的盈利模式已经从粗放期的物理资源售卖转向PaaS大中台，因此核心的高可用基础架构组件承担着公有云的重要赢利点，也是企业负担的主要开销来源之一。
在大数据方面，我们的技术手段仍然体现出适应云原生时代的新一代处理体系。
例如我们很早就抛弃了以Hadoop/Spark 为核心的批处理作业体系，而以Flink为代表的流处理作为数据处理引擎。因为用流系统来模拟批处理作业相比用批处理来模拟流式系统更加直接和优雅。
另一方面，在大数据方案实施中，我们没有传统的ETL概念，因为以Sqoop为代表的传统ETL依赖人工，并不能适应复杂纷繁的企业内部体系架构，更难以适应多变的云端环境。
ETL其工作本身，最容易忽视的特质在于数据管道编排自动化以及容错处理，这些都是我们尤其关注解决的要点，因为这会将我们从繁杂困难的人工项目实施中解脱出来。
另一方面，作为大数据产品的核心部分，OLAP引擎，出于我们对任何数据库引擎底层的了解，我们会选取一些实时性良好的解决方案。
举例来说，最重要的大数据产品之一，可谓用户画像和营销一体化解决方案，我们能够提供实时(百毫秒级)支撑10亿用户的标签计算和标签更改。当然，如果时间允许，开发我们自己的OLAP引擎也并不是不可做到的（事实上这很有必要，但创业公司不能随心所欲）
人工智能同样是我们的强项之一。
不过正如前所述，单纯的人工智能算法，如果缺乏强有力的工程落地，并不能让企业真正受益，因此将人工智能算法工程化落地，是我们极为看重的地方。
举例来说，我们近期落地了以MegaFace百万人脸冠军方案的人脸解决方案，从算法到产品需要一系列辅助设施的开发：
1.边缘计算设备引擎，这需要在廉价硬件设备上运行神经网络的推理加速。
2. 边缘设备管理中间件，这实质上是一套物联网解决方案，可以提供数万边缘设备的资产管理，版本升级以及回滚，远程监控乃至灰度发布。
3. 基于微服务的业务逻辑架构
4. 云端图像搜索引擎。人脸识别模型只是提供了人脸图像的稠密特征表示，真正从大规模库中搜索到对应的人脸信息，实质上是是一种图像搜索。例如百度识图就是这样一种应用。我们开发了高可用强一致并且支持Auto Rebalance的分布式最近邻图像搜索引擎，可以提供3副本情况下亿级人脸数据3ms返回，以及40w的并发查询能力，可以强有力地支撑复杂业务场景。
因此，从简单的客群分析，到复杂的会员识别，大规模支付，等等，都可以采用统一的中台体系，这就是强中台基础架构支撑下的解决方案交付能力。
人工智能和架构结合的层面还包含人工智能框架本身，这方面我们也正投入力量研发。我们根据人工智能对计算资源的消耗，把任务分为两类。
一类是离线型人工智能任务。这类任务的特点是模型训练完毕，就可以拿到inference引擎使用。它们通常的挑战在于：计算密集，调参困难。
针对前者，不得不引入并行训练框架，针对后者，类似自动超参数搜索的概念就是一种刚性需求——前提仍然在于算力充足。
因此，这里边就存在一种巨大的浪费，首先计算资源是非常昂贵的，但是模型训练结束之后，计算资源在很长时间之内都不再需要。因此，为了更加节省开销，需要两方面的工作：一个是更加高效的并行训练如何进行，一个是如何解决算力的问题。
针对前者，由于深度学习收敛性区别于传统机器学习，因此很难采用类似机器学习那种半异步方式解决通信阻塞的问题，我们的工作集中在梯度压缩。针对后者，一个自然的方式是借助于区块链。我们的技术路线则是以TEE可信计算为基础，搭配企业级区块链，实现去中心的并行训练。这里边有几个技术要点：
1. 单个任务的去中心并行训练不可能，因为深度学习本身是带宽消耗极大的任务，带宽的有效利用完全决定了并行效率的高低。因此，去中心训练是指同时在不同节点运行多个任务，每个任务采用不同的超参数。因此，这是一种去中心的自动化超参解决方案，基于去中心区块链的目的在于解决算力不足。
2. 可信计算是为了解决训练数据隐私保护问题，这方面百度已经做出了有益尝试。
另一类是在线型人工智能任务。这类任务的特点是，模型训练完毕之后，要迅速部署到线上，同时模型仍然在不断更新。在很多情况下，模型的新鲜度甚至比收敛更加重要。
典型的场景就是广告推荐领域。这类需求，由于模型巨大，系统长期运行，因此成本和高可用方面都需要额外的考虑，例如GPU就不是推荐的选择，容错设计则远比前一类人工智能需求要高。由于深见网络本身专注于提供企业级的解决方案，因此搭配完善的高可用设计并非难事。除此之外，通过DPDK等技术加速网络通信，从而提升模型的更新频率，也是重要的技术手段之一。
区块链方面，除了前述的去中心化人工智能自动超参搜索系统之外，我们的区块链布局主要围绕企业级需求展开。
由于区块链技术自诞生以来，一些根本的问题并未解决，例如高吞吐量低延迟和安全性之间的矛盾等，因此此时宣称提供了下一代区块链技术，多半是不切实际的浮夸宣传。
事实上我们一直在跟踪下一代解决方案的可能设计，比如基于分片技术提升吞吐量和VRF来尽量不降低安全性的解决方案，但这些仍然面临一些重要技术挑战例如涉及到分布式事务的智能合约等，因此在面临企业级需求时，我们并不会贸然选择，而是会裁剪需求。
例如企业之间合作并不严格需要拜占庭容错，在放弃该假设的前提之下区块链实质上成为一个异地多活的日志系统，这是一个典型的分布式系统设计，以分布式日志系统来看待区块链，就很容易寻找到它在企业联盟中的定位。
为了真正把人工智能端到端生命周期的所有有价值的数据、算法、算力最大限度的赋能广大实体商业，我们给这个AI+区块链平台起了个内部代号，叫做AIEX，也就是AI交易所，其实就是一个保护隐私的数据、算法和算力公链，AI即挖矿。希望我们的平台也能将相当一部分比特币挖矿电力转为AI计算。
