EOS系统架构和传统互联网应用架构对比和解析

EOS最近在Steemit上发布了系统的整体架构，虽然讲得不是清晰，但大致轮廓可以猜出来，本文将做一个简单的分析

原文：https://steemit.com/eos/@eosio/introducing-eos-io-application-stack

架构图

通过对比传统web服务模块，可以比较容易理解各个模块的用途

EOS：eosd
Web：数据库
提供数据存储，只是eosd是基于状态的区块链数据存储方式，以及通过transaction执行智能合约进行状态的修改。

EOS：Query Services + GraphQL
Web：REST & Graph QL & 微服务
EOS应该会把比如用户账号管理、转账等封装成微服务；GraphQL在React框架里使用已经比较简便。
名词解释：GraphQL 是一个由Facebook提出的 应用层查询语言. 使用 GraphQL, 你可以基于图模式定义你的后端. 然后客户端就可以请求所需要的数据集。

EOS：Client（React.js）
Web：前端
因为EOS架构中将GraphQL默认集成，那么前端使用React.js将是最优的框架选择，所以有意给EOS开发应用的开发者可以关注React多一些了

EOS：IPFS File Storage
Web：文件存储
从架构图上看包含了文件的存储，和服务器端程序的存储；并没有明确是用filecoin的链，还是基于IPFS协议有block producer提供存储；文中说是免费的，所以应该是基于IPFS自建；说是免费的，但同时和代币持有量有关，这点文中还没有讲清楚。

思考：

1 类比目前互联网应用的架构模型比较方便开发者上手，同时也提供与目前互联网应用类似的体验
2 支付模型目前看不清，但与以太坊按计算量付费的模型相比EOS目前描述的模型非常复杂和动态，因为EOS不止需要限制计算，还要限制带宽、存储等
3 最后文中也提到应用开发者可以通过类似的架构来提供链外数据接口，从而实现应用的高可扩展性