业务应用开发
如何搭建一个简单的区块链应用，终于走到了最后一个阶段，前面我们已经完成了区块链上智能合约的开发，以及链交互模块的开发，现在我们就来看看最后的业务应用的开发吧。
我们先来整理一下开发一个区块链应用的基本逻辑吧。软件应用是需求的解决方案，所以做软件应用就是做一套解决方案去解决现实的需求。一般，拿到需求，先做需求分析，需求筛选，需求排序等，最后打包出最终的需求。紧接着，做产品规划和概要设计，规划产品架构，设计出产品原型。拿到产品原型，前端可以开发静态页面了。后端这边，搭建区块链一整套环境，设计数据模型，设计系统架构，开发智能合约，开发链交互模块，开发业务应用后端。前后端对接，组合完整应用，测试部署上线运营。
业务应用的开发不与区块链直接交互，业务应用只与链交互模块的开放API交互。因为前面我们已经解耦出了链交互模块，所有与链相关的交互全部由链交互模块完成，可以把链交互模块理解为业务应用和区块链交互的代理。
业务应用的开发可以理解为传统Web2的开发，前端的呈现形式目前主要有Web、小程序和APP，后端的话，主要就Java和Go两套。业务应用的前后端正常走外网HTTPS方式交互，后端和链模块之间走内网HTTP方式交互。
在NFT场景下的业务开发，之前也遇到一些问题，就抛出来和大家一起探讨吧。
问题1：在抢购高峰期，出现两个用户抢到同一个商品。这是因为在非常接近的两个请求中，两个用户会“同时”创建同一商品的订单，支付成功之后，就是买到同一个商品啦。这是常规的电商问题，针对同一商品的重复购买，可以通过数据库的乐观锁、Redis锁等方式解决。增加锁之后，两个非常接近的请求，只有一个会成功，另一个拿到失败的结果。当请求再次发起时，在查商品库存时，库存为0，请求将会被打回，不会往下走，不会购买成功。这样就保证了，一个商品只会被一个用户购买到。
问题2：短信验证码或实名认证接口被盗刷。短信验证码或实名认证接口如果没有增加限制的话，开发者可以扒出接口，然后写个程序循环调用。攻击者低成本盗刷平台云服务接口费用，尤其实名认证的四要素验证，盗刷一天的话，可以花费掉平台几十万的云服务费用。这种场景下，可以限制接口的调用频率和调用次数，同时追加图文验证码，尽可能堵死盗刷接口的可能性。
问题3：链服务转移压力大，导致转移失败。区块链存在性能瓶颈问题，这是由区块链本身的性质决定的。所以一些业务需求应该在业务层实现，而不是区块链层实现。链交互模块作为一个解耦服务，应该尽可能小地与业务关联，主要做与链上合约的交互并提供一整套调用API即可。所以针对链服务转移压力大的问题怎么解决呢？一种是在链交互模块做接口频率调用限制，业务层针对调用失败的请求，放到失败队列，继续调用。高级一些，可以在链交互模块开一个MQ请求队列，把队列中的请求顺序执行，业务层异步接收执行结果，可以是回调方式，也可以是主动请求方式，建议两者结合使用。另一种是主要在业务层实现，业务层做频率限流，保证不超过链服务压力阈值。业务层实现的话，主要通过MQ实现，请求优先放到MQ，然后顺序平滑执行链服务调用，可以开多个消费端同时调用。这样，就解决了链服务的压力问题。
问题4：支付频繁，导致支付回调丢失。支付服务中，在支付成功之后都会收到异步通知，即支付服务主动请求业务层，通知支付结果。在带宽有限，高并发的场景中，支付回调的结果是有可能丢失的，导致用户购买掉单，付了钱但是没有买到商品。这种情况，建议把支付模块解耦出去，支付模块单一负责支付业务，支付模块部署在其他服务器。这样，支付模块接收支付回调结果会与业务层独立，完全不受业务层的影响。支付模块和业务层之间通过HTTP或MQ方式交互。如支付模块接收到支付回调结果，把消息HTTP方式主动发送到业务层处理，或者通过MQ方式在业务层做消费。这样，不但解耦了支付业务，提高了支付业务的维护性和扩展性，也提高了整个应用的性能和可用性。
问题5：抢购高峰期，应用瘫痪。用户数激增，突破应用承受瓶颈，整个应用瘫痪。针对这个问题，主要从业务层和配置层去解决。业务层可以把抢购页面静态化，提前把必要数据预热到Redis，降低数据库的压力，提高页面加载性能。抢购过程中，使用MQ削峰填谷，平缓有序处理业务，分散服务压力。关于应用的中间件配置，也需要根据用户量预期和硬件条件，调整到合适的参数，如调整Tomcat参数、JVM参数、Nginx参数、程序连接池参数、MySQL参数、Redis参数、MQ参数、OSS参数等，尽可能提高中间件性能的支持。最后，还需要配置预防策略，通过阈值方式保证应用的正常运行。使用Jmeter、PTS等压测工具，压测出应用的瓶颈，再使用Sentinel或AHAS等设置限流降级熔断策略，保证高并发环境下，应用的可用性。再高级一些，还可以使用SAE等产品实现动态扩容与缩容，按需供给，甚至动态增加或减少服务数量，提高网站的容量峰值。不过，动态增加或减少服务数量的话，需要把应用的状态数据抽离出去。只有全是无状态数据的服务，增加或减少服务数量才不会影响应用的可用性。
解决了这些应用难点，一个强健的业务应用也就诞生了。至此，就可以加码运营，绽放异彩啦！奥利给。
