芯片族探索互联网+的新视角



芯片族探索互联网+的新视角

廖恒

      由于产业的分工，作为芯片族的一员，要理解互联网+对硬件系统发展的影响实在不易。我们与互联网+的具体业务之间隔了设备厂商、系统集成、互联网平台（如公有/私有云平台）、业务开发运营者等诸多层面，最后才能到达用户的直接体验。要理清这些日新月异的新服务和我们芯片之间的关系，找到今后芯片的方向，就像作为单个细胞要理解整个人的高级思维一样，隔了几层天，可谓瞎子摸象。

      偶然的机会让我开始尝试一个视角—软件开发者的角度。如果我想理解一个大型电商平台对存储芯片的要求，是否可以尝试开放一个简化版的电商系统？同样，我们可以用实践的方法来思考其它互联网+应用的开发者面临的层层选择。比如：实行办公室公有车位便利共享？上海车牌的拍卖？有机蔬菜的配送服务？观鸟爱好者分享稀有鸟类的地理位置？当然这里说的实践并非真正完成软件开发的整个过程，只是尝试把自己置身在这个软件应用开发的过程当中。

      当大家都把眼光盯在中美两国的互联网巨头的时候，可能忽视了互联网+的无数新应用还会来源于分布各地单薄的个体。这些小众应用固然不见得能直接产生利润，但它们能为具体的人群带来实在的便利。今天业已存在的便宜的云服务和丰富生长的软件生态体系都为小众应用提供了有力的支撑和实现的可能。由于云服务的价廉，使得个人的支出就可以购买足够的虚拟资源来运营一个小应用。而丰富的软件生态，把过去要投入几百人年才能实现的功能在个人的时间精力范围就可实现一些有用的互联网服务。技术发展到这个阶段，一切都有可能。这是个另类的互联网思维－－不赚钱的互联网思维。

      于是我在封刀二十年后试图重新学习做程序员。我的起点和大学新毕业的从业者差不多，重新学习现代编程语言(JaveScript,Python, SWIFT, Objective-C)，快速更迭的互联网框架软件术语(PHP, JASON,.NET)，还有(Client/Server, Backend/Frontend, Apps/HTML5)等基本系统架构的概念。我面临的困难在小众开发者中有相当的代表性。

      作为开发者面对的首先是用户界面的问题：如何提供一个界面和用户交互？自然有如下几个选择：

1）Wechat–交互界面通过发消息到一个Wechat公众号完成

• 好处：任何智能手机用户都可以直接使用，跨平台不需要部署客户端。

• 坏处：能实现的界面相对简单，只能选菜单等，对复杂操作，难以实现直观便利的界面。

• 服务器端： 要和Wechat服务器进行交换。

2）HTML5–通过网页来实现图形界面：

• 好处：任何新的智能手机都能实现，不需部署客户端，与平台无关

• 坏处：WebServer设计较复杂。网速慢会直接影响用户体验（如果网站放在国外，基本就不能用了）。

3) App –提供App来实现客户端界面

• 好处：用户体验可以最佳。界面可以无限扩展。

• 坏处：需要为每个平台开发App,编程语言和API完全不同。

      现在来看看服务器端，这才是我们直接关心的领域。为了支撑前述的各种用户界面的方法都需要实现某种后端功能。我们来看看这意味着什么。

1）服务器的部署：公有云服务提供了网络接入，物理计算存储的资源，也可解决域名注册和定向等基本服务，解决了后端基础设施的保障。

2）后端软件系统在PaaS/BaaS/SaaS之间的选择：以App方式为例：

a)　PaaS,即在公有云的虚拟机上完全自主开发整个后端软件功能．开发者还要考虑容错，业务扩展性等问题进行合理设计。

b)　BaaS后端服务以抽象的云API的方式呈现(例如Parse.com)，而不需要关心在那个物理／虚拟主机上运行，通常Baas提供基本对象存储，共享数据结构存储和操作等基础功能，另外还提供用户注册，认证，支付系统，通告，邮件等等增值的功能。在此基础上开发后端系统可消除大多数服务器端的代码量。而且BaaS所实现的API本身就已经是基于向外扩展的构架，所以具有很好的可扩展性。小众应用不小心井喷式增长（变成大众应用），也不用推倒重新设计可扩展的后端系统。

c)　可定制化的SaaS，例如，你如果需要开网店，可利用电商SaaS (如Shopify)提供的较为完善的整套电商系统方案，店主只需开个账户，往里面输入商品目录等等来定制网站的内容，整套电商网站业务系统就可上线了。整个过程不需要编写一行代码。而且一般的SaaS也具有良好的可扩展性和容错。

      回到我们的芯片本行，以上的思想试验带来的启示是什么呢？

1)各种层次的云服务已经是新互联网的主要选择。互联网＋必然会推动云服务的高速增长。而我们过去关注的互联网巨头应用固然重要，小众应用可能会成为云服务的下一波推手。

2)云服务的层次可能很多，在PaaS式的基础设施服务之上可以堆叠BaaS, BaaS上可堆叠在针对行业的可定制化的SaaS。随着每一个层次的堆叠，实现具体应用的开发工作量数量级的递减，而业务的代码质量和可扩展性数量级的提升。在此过程中，该层服务的开发者也创造了巨大的价值（如Shopify电商平台上运行了16万个在线商店，这也就意味这不需要有16万个开发团队重复地开发功能类似的电商平台软件）。

3)每一层云服务的API给芯片构架师们提供了一个天窗，通过这个天窗，我们可以看到跑在这一层之上的业务是如何存储／访问数据，需要完成什么操作。而越往上层，通过该层的天窗我们看到的操作和需求越具体精确，同时适用的范围也就越局限于某个子类别的应用。

举例说明：通过AmazonAWS/S3，我们可以知道对象是如何存储，如何访问。

通过AppleCloudKit,我们看到支持Apple iOS/OSx App的云后端对象，记录，数据库，用户信息，推送信息等如何完成。

通过ParseAPI，我们看到支撑跨iOS/Android平台的云后端更丰富的语意的API.

通过ShopifyAPI,我们可看到支持电商平台所需的数据存储和操作原子。

      作为芯片从业人员，这些一层层的天窗提供了有用的启示。从中我们可以想象到存储芯片在支撑这些API调用时所需进行的操作和频度。还可看到不同介质适用的数据结构类型，以及访问它们的方式。还看到存储和CPU不同程度得耦合关系，还有改变硬件接口方式可能带来的对API调用的便利和效率提升。这些都是以往没法直接得到答案的问题。今后我们会对每层云API进行具体分析，并分享我们得出的看法。这样我们就从瞎子摸象变成了透过天窗看大象。