安全开放性云平台架构与设计

       本篇也是我在某司担任产品总监时对产品开发上和架构设计的思考，现已离开这家公司一段时间了，对该产品依然恋恋不忘，现将这些思考记录总结下，算做一个缅怀。
       是什么原因会导致我们需要对该平台开放呢？以及如何做好开放后的安全措施呢？
       首先谈论第一个问题，我们当时研发的是音视频云广播的整体解决方案，包括音频广播终端，比如云功放、云音箱（壁挂式、桌面式、吸顶式等等）和正在规划中的视频终端，以及包括对这些终端进行控制和交互的APP，包括IOS/安卓/WEB，再者就是云平台和操作运维系统了，总之麻雀不大，五脏俱全，那这么一个在产品和技术上什么特点呢？
       1. 产品市场领域广，音视频的广播可以应用到超市门店广播、城市公交和地铁的广播、幼儿园和学校的广播、城市安防广播、景区广播等等；还有一块非常大的应用范围就是家庭娱乐的广播，比如wifi音箱，智能音箱等等，这么广的市场，那作为前期产品的研发我们最需要解决的就是核心需求，对平台提供最大限度的抽象，因为面对任一个特定行业时，这些细分行业也必定会有其行业特点。
       2. 定制需求多，在广播这个行业，因为历史的原因，各自都有他们的系统，但是大多的核心的需求都是音视频的广播，比如远程实时喊话、定时任务广播、文本转语音播放等等，但是公司是一家研产供销性的公司，需要支撑某些OEM的需求，比如在调研幼儿园广播时，我们就遇到一个需求，提供报警功能，比如厨房失火，那么听到报警后，可以及时进行相关处理，这在幼儿园是非常合理的，但是如果你是架构师，如何解决这类的定制需求问题？云平台需要做到扩展性设计，业务能力的扩展性，你不可能是一个行业去做一个系统吧？还有既然行业不同，客户不同，那么他们还会存在对交互设计上的要求，比如幼儿园的界面要做得卡哇伊一些，比如安防交通领域和家庭娱乐方面可能都会有所不同，这对于一个解决方案来讲，就非常适合云平台提供基础功能，不同行业就是对这些基础功能的一个集装的实现。
       3. 平台对接，有研发能力的客户都有自己的系统，比如我们接到某省的公交和广播组建的公司，他们已经有一个比较完善的系统了，需要在公交车上集成音频广播需求，在实际开发中我们就需要在他们的系统中集成我们的方案。
       4. 多平台交互，我们目前实行的交互平台主要有IOS、安卓和WEB，但是我们都知道现有很多公司和门店都在微信公众号、微信小程序和支付宝小程序上面做一些推广，而且这些都只是一些交互设计，都是要与后台通信的，那我们也是必须对这些进行统一封装。
       5. 公司的业务研发能力不强，在产品管理和研发上的确比起很多沿海城市的企业要差一些，那么为了长远发展，我们就需要客户完成他自己的一些事情，甚至我想到我们平台不仅是接口开发，最好是能像windows的钩子机制一样，做好基础数据和框架开发，可以让客户写好自己的业务逻辑继承到平台，这样就能够最大限度地解放我们，也让客户做他们想做的事情，岂不两全其美。
       深入分析了这些的特点后，跟一些同事也分享过这些想法，也得到了高层的肯定，尤其是一些市场同事的反应，于是打定一个主意开放云平台，提供终端硬件的整体解决方案，自己专注某一两个行业做整体行业解决方案，让大部分基于我们的云平台和终端硬件方案做他们想做的事情。
        这个想法，其实在一定程度上学习了萤石云和科大讯飞他们，可惜始终觉得一个想法来自我一个技术出身的人，而不是来自市场业务团队，我觉得我们的销售团队还真不是很懂我们的产品（PS：顺便挖苦了下市场团队啊）。
       那既然要做接口开放，那如何保证安全呢？
       TCP或者UDP此类接口明显不合适，那https呢？https基于SSL协议做到了安全，可是https耗时久效率低，在服务器端要想提高效率需要https插卡，而且在国内CDN大多不难支持https，所以为了长远和显示利益没有考虑https。
       后来仔细分析过微信和萤石云的实现，其实这是一套完整和完善的解决方案。
       首先谈安全登录，如果我们采用直接加密用户名和密码的话，虽然不会泄露明码，但是如果抓包分析这两个字段后，填写一样的加密的字段，那也还是可以伪造调用接口的，而且调用http接口时必须要知道用户身份和验证用户身份，如果每次都传输用户名和密码的话，无疑增加了暴露风险，业界都是采用token来实现，token就是一个授信令牌，用户第一次登陆时发送加密后的账户和密码给服务器，服务器解密后验证账户和密码，如果通过验证则按照某种加密算法，将用户信息加密生成一个token，然后保存uid、token和exp（过期时间）到缓存服务器上，同时把token传回给客户端，以后客户端每次通信都带上该token值，表明用户身份，这样就不需要传用户名和密码了，最大限度保证了账户安全，如下：

token机制.png
       但是利用token只是保障了用户账户的安全，如果我们从网络上抓包分析，还是可以获取这个token值，那么就可以利用此token向服务器发起请求，获取云平台的数据，或者恶意攻击，那又到底如何做好这个安全问题呢？
       1. 平台开放了，那就要识别第三方开发者的身份；
       2. 验证http调用的合法性；
       3. 防止恶意攻击，或者第三方调用不当；
       4. 如果能解决以上问题，其实我们还可以通过这些搞定对流量的统计和调用次数频率的统计，搞定我们市场业务，比如按照流量收费和按照调用次数收费。
       详细步骤：
       1. 开放一个开发者注册平台，第三方可以注册开发者账号，分配一个appkey（第三方调用者身份标识）和secret（一个秘钥）。
       2. 开发者调用接口时除了需要获取token外，还需要再每次调用时把appkey和token这两个参数携带上；
       3. 添加timestamp，保证调用的唯一性，于是http的url可能如下：
http://api.XXX.com/getproduct?id=value1&appkey=XXX&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9&timestamp=12445323134](http://api.XXX.com/getproduct?id=value1&appkey=XXX&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9&timestamp=12445323134
       4. 把所有参数进行字母升序或者降序进行排序，然后按照某个加密算法进行加密，把加密后的值作为一个签名，比如：sign=78093C377FDE63280F990CA9D8FAF0C2ED6ACAEA。
       5. 最终把sign也填写到http里，如：
http://api.XXX.com/getproduct?id=value1&appkey=XXX&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9&timestamp=12445323134&sign=78093C377FDE63280F990CA9D8FAF0C2ED6ACAEA](http://api.XXX.com/getproduct?id=value1&appkey=XXX&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9&timestamp=12445323134&sign=78093C377FDE63280F990CA9D8FAF0C2ED6ACAEA
       对于云平台来讲那就是首先检查appkey、timestamp、token和sign四个参数是否存在，如果存在，则继续；否则拒绝次请求。
       继续对http的所有参数（sign除外）部分利用相同的加密算法进行加密，生成一个签名，去比对http里传过来的签名是否一致，如果一致则是合法调用，拒绝此调用，当然我们也可以统计调用的频率，如果超过某一频率，则规定多长时间内拒绝该请求，比如10秒或者10分钟或者1个小时内不再接受该第三方调用者的请求。

更多交流请入QQ群【554271674】