接上一篇个人API服务器的架设(BitShares API 服务器架设指南(一) 个人篇)，这一篇探讨一下公共API服务器的架设。目前暂时还没有最佳实践的规范，行业内很多比特股技术爱好者和先行者都在摸索尝试，也希望这篇文章能引起大家的关注，一起来探讨如何能够最有效的架设公共API服务器，为更多用户提供数据支持服务，提升用户体验，从而推动比特股生态的发展。
公共API服务器一般架设在Linux服务器上，也面向专业技术用户，所以文中更多用命令或者代码来阐述，少了些描述性文字。欢迎技术同好轻拍。因为我目前架设的服务器主要面向国内用户，所以服务器的选择，域名解析的选择，包括本文用中文写，多偏向国内的使用。
我们这里谈到的 API 服务器，实际上有以下几种用法，不同的用法，硬件要求及配置上有很大不同：
主要是个人用户在使用轻钱包或者网页钱包时，使用运行在本地，独占使用的API服务器。现代的个人电脑配置基本就足够了。请参见个人篇。
提供一个公共的API服务器，向服务。一般需要是托管在IDC的服务器或者从云服务提供商那里租赁的VPS，对配置带宽都有一定要求。
这部分就简化了，大概人人都会，可以去godaddy注册，比较便宜，选择也多。国内的域名注册商也是可以。不过需要注意到是，如果租用国内的服务器，域名必须完成实名制和备案。否则会造成域名访问被屏蔽。
我一般喜欢注册完后用 dnspod 来做域名解析。在国内解析效果不错，很稳定，如果升级到付费套餐的话，提供更多的智能线解析，还有A记录，CNANME记录的负载均衡选项。比如在南方机房配置了服务器，也在北方机房配置了服务器，通过域名解析自动指向离用户最近的服务器，这样可以在第一个环节提升用户访问时的速度。当然还有个因素是如果站点访问量比较小，DNS解析量少，local dns就几乎没有缓存，理论上解析速度就慢，反之亦然。
国内其他的域名解析商提供的服务之间的比较我没有深入研究过，比如阿里云的DNS，口碑似乎还不错，欢迎各位补充，这个话题可以聊得很深。
我们现在知道API服务器在提供服务时，以下几个要素需要特别关注：服务器带宽、内存、CPU。经过测试，我觉得下面的架构比较合适。前置一台nginx服务器进行负载均衡，将wss请求分配到后段的多台节点服务器，可以根据使用状况，或者增加后端节点服务器，或者增加nginx服务器的带宽是配合实际需求。
在测试例子中，我在阿里云上租用了2个ECS示例，配置都是8核32G，硬盘空间不算贵，各挂了200G的云磁盘，好在IO读写不吃紧，问题不大，所以没用SSD;1个RDS示例，配置可以最小的，为水龙头服务准备，非必须。其中一台仅作为节点服务器，运行witness_node，另一台充当多个角色，即作为节点服务器运行了witness_node，也运行了nginx，充当web服务器。喜欢干干净的话最好各个角色出来。
我们并且在2台服务器上创建了用户deploy，用户目录位于/home/deploy，用户有sudo权限。
以后我们就用deploy用户通过 ssh 访问系统了。这里最好配置 sshd 以后不允许 root登录，也不允许使用密码登录，只允许用PublicKey登录，摘要如下。
所以，后面的代码例子都是以deploy用户执行的，必要时才进行sudo进行提权。这里只是最基本的安全设置，再怎么强调安全都不为过，如果是生产服务器的话，请进一步加强安全方面的配置。
数字证书可以认证服务器身份，防止钓鱼网站;同时对用户浏览器与服务器之间的数据传输进行双向加密，防止传输数据被泄露和，抵御中间人。所以，提供公共API服务，请务必给你的站点加上SSL证书，并让服务运行在https(wss)上。wss是Websocket Secure的缩写，是加密版的Websocket协议。
SSL证书没有所谓的“品质”和“等级”之分，只有三种不同的认证类型。SSL证书需要向国际的证书证书认证机构(简称CA，Certificate Authority)申请。
?DV (Domain Validation)：域名认证。信任等级普通，只需验证网站的真实性便可颁发证书网站
?EV(Extended Validation)：增强型，信任等级最高，审核严格，安全性最高，同时可以激活绿色网址栏。
显然通配符证书更灵活，常常开始时，你只想着我只需要一个网站就好了，渐渐发现还需要api域名，静态资源域名，后端中台域名等等，如果使用前2种就比较尴尬。
国内的主要云服务商都有提供SSL证发服务，有免费的，国外StartSSL(，Lets Encrypt(教程并提到比较多，我自己喜欢用 RapidSSL 的这个通配符版(的，价格还合适。
不同的服务商申请时细节或有不同，可参考服务商网站上的详细帮助，但是基本上都包含以下步骤，以购买RapidSSL? Wildcard Certificate(，支持通配符，为例。
1 购买证书：访问网址，选择证书年限，比如2年，到期需要续约。加入购物车后填写基本信息完成支付。
2 完成支付的订单，会要成一个certificate，提供common name，就是你的根域名，比如dexhub.io。选择验证方式，邮件或者网页。我选择了网页，也就是到时候需要根据要求在网站根目录下放置一个文件，能被读到，那就证明了我对这个域名的网站是有管理权的，通过这个方式来实现域名认证。
3 下一步就是要根据提示生成CSR(Certificate Signing Request)文件了，这个文件的意思是要在你的服务器上使用服务器端私钥签署一个包含了网站、组织信息、域名等信息的文件，来证明证书请求真实有效。将来最后发行的证书需要服务器端私钥配合才能工作，如果私钥丢失了，这个证书也就等于失效了。所以务必备份。
那么生成CSR，我们首先要生成服务器端私钥，我们只需要在nginx所在的服务器上生成私钥，前面讲到的架构中，由nginx和后端节点服务器进行沟通，他们之间不使用secure协议。
现在 /etc/nginx/ssl 目录下有两个文件了，server.key 和 server.csr，前者是有密码的服务器端私钥;后者是CSR文件。我们需要把CSR文件的内容复制黏贴提交到RapidSSL网站上要求我们输入的页面中去，如下图：
点击 Continue 后进入下一页，显示CSR中decode出来的信息，你可以再审视一遍，确认后提交。如果成功，会出来下一步提示，要你在域名根目录下创建文件，包含特定内容，确保能被访问的，从而被验证。
然后就等着吧，快的话几分钟后就能收到邮件，说是Approved了，这个是应该很快的，因为都是自动的。然后根据邮件里的提示进行了。还是那句话，不同的服务商略有不同，照着提示做就可以了。
这里我就略过了，最终拿到的是一个 server.crt 文件，我们把它放到/etc/nginx/ssl目录下。现在目录下有3个文件：
之前我们生成的server.key是有密码的，我们现在去掉密码，这样nginx就可以自在的启动了。
这里有个 ssl_conf 文件被include了，这是什么呢，我们把SSL相关的配置都放在这个文件里，内容如下：
# 这里，我们假设将目的地目录设置在 $HOME/src/bts_source，可根据需要修改
编译的操作并不需要在每一台服务器上都进行，一般来说配置的节点服务器的配置和是一样的话，那么选择其中一台进行即可，完成后可以将编译出来程序直接scp到其他节点服务器上去即可。
我们在 $HOME/src/bitshares-core目录下创建一个 copy_to_build.sh 文件，负责将编译后的程序复制到 build目录下。虽然在 make 的时候可以直接指向目的地过去，但是在过去的版本中曾经有bug导致失败，所以就用笨一点的办法达到相同的目的。这样以后BitShares有版本更新，编译完直接执行下就好了。另一个原因是我们要在一台服务器上跑多个节点，这样复制起来更方便些。
witness_node节点的运行要求当前的服务器器校准时间，在之前安装依赖的时候有安装ntp，请确保没有遗漏。
这里使用了-d node_data意思是将区块链数据以及配置文件放到node_data子目录下，不指定的话会创建一个叫witness_node_data_dir的目录来存放，我不喜欢这个名字，所以就用这个，纯属个人怪癖。
启动并终止后，多了个node_data的目录，里面有不少东西，其中是配置文件。命令行下的参数基本上这里面也都可以设置。
# 重发所有已下载的区块并重建索引，非常耗时。当意外中断后重启会强制进行，所以尽量不要强制中断，按了Ctrl+C之后稍等一会儿等程序完成收尾工作后优雅退出。
--track-account 参数的意思是我们只关心特别指定的账户的历史交易信息，其他账户的历史交易信息我不需要。这样就可以大大节省内存开支。这在架设供个人使用的API服务器时非常必要，但对于公共API服务器则不适合，所以千万不要设置该参数。
而对于节省内存开支，以下两个参数非常重要，他们是 partial-operations和max-ops-per-account。如果不设置，目前状态下，一个全节点公共API服务器大约要占据24G的内存，太厉害了，配置了这两个参数，将大大降低，目前测试情况下大概在5G左右，当然这也和访问量有关系，但大大降低是肯定的。
--partial-operations 这个参数只需要部分的数据。这个参数可以在启动命令行加入，也可以在config.ini中设置。
--max-ops-per-account 这个参数的意思是在内存中对访问的每个账户保持最多n条op记录，如果不设置则是全部。而一般用户使用时，很少需要看到很早以前的历史记录，所以，可以设置一个较小的值，比如500.
我们不打算并在localhost上，而是绑在内网IP上，原因是，我们打算让nginx通过反向代理来访问，而节点服务器和nginx并不在一台服务器上(当然，我们前面架构图中，有一个节点和nginx在一起，它就可以并在localhost上)。
所以，我们可以把启动命令都放到一个脚本中，不需要再在config.ini中设置了，这样方便运行和迁移，当然config.ini 其中还有很多选项值得探索，有的并不支持在命令行中使用。
应该注意到，我们目前是在node1目录下进行配置，那么在node2目录下是一样的，可以将run.sh复制过去，但是端口需要修改一下，比如设置成18090。
下面我们就要启动节点了，可以使用upstart来控制。这里我们先用screen来模拟2个终端，让任务持续执行。
2个节点启动后，就需要耐心等待区块同步。在未完成同步之前，如果尝试使用客户端进行连接，也能连，但是会出现“区块数据陈旧或时钟不准”的错误提示。
有一点注意，不要为了节省磁盘空间，想着让2个节点共享数据目录哦，2个的进程都在写数据，会发生很混乱的状况。目前的已同步的区块目录磁盘占用不超过20G。
同样道理，我们在ECS A nginx 服务器上也跑一个节点来做测试，毕竟内存配得多了，闲着也是闲着。启动命令中ip和端口我们就设置成 --rpc-endpoint 127.0.0.1:8090 用默认的即可。
我们希望ECS A是唯一对外的服务器，ECS B则躲在后面，我们也只对ECS A8090和18090两个端口。我们在ECS B上用ufw来创建几个规则。
大部分比较容易看明白，其中对js/css/dat的处理是考虑钱包的都是静态资源，对他们设置些缓存选项。
/ws部分，则通过发向代理去到 upstream nodes部分。upsteam 部分了一组节点列表，分别是2个指向ECS B和一个指向本地的节点。后面注释掉的是可选用的选项。ip_hash很重要。因为websock是持久连接，可不希望客户端在连接时一直不停的在后端不同节点间跳跃。所以ip_hash的作用就是nginx一个根据客户端ip和分配的节点的映射，让同一ip地址的客户端始终连到同一个后端节点。
到现在，实际上我们的公共API服务器已经完成啦，可以去告诉小伙伴们来试用 wss://wallet.dexhub.io/ws作为钱包接入点了。
我们这里就简单的复制钱包来伺服就好。当然最好是下载了钱包源码自己编译，或者做些自定义修改更佳，那就是另外一个话题了，或许以后另开一篇讨论。
之前nginx我们已经配置了wallet站点了，现在就可以去试试看访问了，我们发现能看到首页，但是不能正常进入，enoou仔细一看，原来官网的钱包是放置在 /wallet径下来访问的，所以资源都取不到，那我们就rewrite一下跑起来再说。在wallet.dexhub.io.conf 中增加：
再访问就行了，钱包网页打开后，可以手动添加 wss://wallet.dexhub.io/ws作为接入点。最好当然是我们的接入点可以在默认列，那如果API服务稳定了，就去github提交pull request加入默认接入点列表为更多人服务吧。
运行了一段时间了，每个witness_node程序平均占用大约4.5G左右的内存，实际上目前在ECS B上跑了3个节点，ECS A上跑了1个节点，也就是说 nginx 后面有4个节点在服务，比较稳定。
过去几周间，经过了yoyow和OracleChain的两个ICO，BitShares的访问量增加很多，观察下来似乎是带宽的瓶颈更大些，在带宽足够的情况下这个架构可以支持更多用户的使用。
写得有点冗长，能看到这里的估计都是真爱了，谢谢各位看官，也感谢@abit 协助审校。受个人学识和经验，文中不免或有错漏，欢迎大家。架构优化是条没有尽头的，面对并发100/1,000/10,000用户的架构和程序设计是完全不一样的，并没有一招通吃的数，在资源有限的情况下。我也不赞同过度优化，随着用户的增加逐渐演进是更有效合理的。的设计针对目前的需求应该还是有一定的可拓展性的。
这是 BitShares API 服务器架设指南 文章系列中的第二篇，公共API篇。上一篇是关于个人使用API的BitShares API 服务器架设指南(一) 个人篇。
如果你喜欢这篇教程，请为我的人投票，在 BitShares 网络上， 我的人叫 mr.agplorer，我同时着一个公共网页钱包以及一组公共 API 服务器wss://bitshares.dacplay.org/ws，示例中使用的 dexhub.io 是随着文章撰写架设起来的真实存在的站点，因为在国内还没有备案，所以暂时指向国外服务器的一个临时站点，没有启用 https，不过 以及 wss://wallet.dexhub.io/ws 是可用的，我打算之后可能的话继续这个站点的服务。
本文由 恒宇国际（www.neivn.cn）整理发布