云知声研发平台总监张劲辉：人工智能公司云服务的打造

　　近日，云知声IoT研发平台总监张劲辉在Ucloud主办的中国云计算行业盛会Think in Cloud上发表《人工智能公司云服务的打造》的主题演讲，他表示，目前云服务已经成为一种业界常态，如何在高频次复杂需求的情况下提供高效的AI服务，可以引入“微服务”的解决方案。

　　云知声是一家借助语音识别为切入点的物联网人工智能公司，2012年9月，上线了国内第一家免费的语音云平台UniCloud，并率先将深度学习引入到语音交互产业领域。目前，云知声云平台的日调用量已经超过2亿次，覆盖的城市超过647个，覆盖设备超过1亿台。

　　微服务架构和语音云平台的结合

　　张劲辉表示，“一个服务刚开始是很简单的，后来做着做着就越来越大，可能包罗万象什么都会有，比如说用户的登录注册，包括通讯、数据库、数据库分表逻辑的耦合，都会在这里面，这说明什么?并且经常是一旦产品上有一个需求变化的时候，技术团队需要从头改到尾。包括在安全上的一些考虑，例如这个接口有没有加校验签名，是否都需要从头改到尾。在这种情况下，微服务设计的引入是非常重要的。”

　　微服务的优势是什么?

　　第一，可以提供端到端的解耦，以及并行的开发、持续的集成和发布。第二，合理的颗粒度切分，一定可以提高应用系统的复用性，以及平台服务的高可靠。第三，我们可以让研发团队技术路线更为丰富，以及团队管理成本更为降低。各应用体系对外有明确的边界和接口，用什么语言和技术手段的重要性和必要性就会降低，所以就不会出现一个公司的技术体系是依赖于一两个技术大侠来支撑的风险。

　　最后的一个核心问题，是如何提供给业务层面，快速的低成本的试错能力，以及业务变化的适应性能力。任何一家公司商业模式包括产品路线，都是经过不断的尝试，所以如何以一种方式有效的帮助产品去快速试错和验证，或是减少它明显的错误，以及降低它的试错成本，本身就是技术团队应该解决的问题。

　　所以光懂写代码的研发不是一个合格的研发，研发必须得懂业务，必须得对业务进行抽象和理解。

　　古希腊有一位哲学家对这类问题有着更加深层的认知。“一堆建材不能叫做房子,如同一群暴民不能叫做军队一样”。希腊不仅有着光辉的历史和哲学，以及我们熟知的经济危机，还可能是“微服务认知的最早起源”

　　微服务的弊端

　　有利就必有弊，当把很多的服务从大往小的敲碎的时候，我们会面临什么?第一，会面临运维成本的增大。更多的服务也就意味着更多的运维资源的投入;第二分布式系统的复杂性，意味着开发者需要考虑网络延迟、容错、消息序列、不可靠的网络、异步交互、版本控制、负载等;第三，开发人员经常犯的毛病，从架构的角度来说，要防止超前设计和过度抽象的问题。

　　微服务在云知声云平台UniCloud中的应用

　　“我今天主要从两个应用角度来阐述一下微服务在云知声云平台UniCloud中的实际案例，第一个是用户体系的统一认证，第二个是使用场景下的双向实时通讯。”张劲辉称。

　　用户有多种登录鉴权的方式，包括和不限于用户名+密码、手机号+验证码、声纹、指纹、人脸识别，以及第三方Oauth方式等。并通过生成token和其生命周期的管理，保证在使用上的安全性，以及与应用服务逻辑的解耦，提供统一的用户安全策略(密码更改)和登录策略(多登录状态)的支持。

　　第一步，登录鉴权，不同方式对应不同的登录接口即可。第二步，生成并返回一个token。应用服务在使用ID化的时候，我们可以把他的业务模型抽向成某个ID要做什么?当使用该逻辑时就把token传过去，应用服务为了要识别这个token只能来验证token。这样的一套服务体系，我既可以掌控应用的用户权限，也可以不打扰它的应用逻辑的业务，实现高内聚、低耦合，以及用户级别的安全的策略。

　　再举一个例子，消息服务提供统一的双向实时通讯支持，支持手机客户端和各种可穿戴设备场景的通讯需求;实现三种业务抽象，就是端到平台(上行信息)，平台到端(下行信息)，以及端到端。

　　用户接入的时候来获取他使用的协议连接点，然后接入到集群和消息服务，使用定义的Massage去通信。消息服务针对应用服务抽象了几种事件和标准接口。

　　第一，用户连接了(上线)。第二，用户离线了(下线)。第三，收到消息。第四，发送消息。

　　整个一个架构是能够支撑以任何一种协议都能够接入的，不管你是用的TCP还是UDP，以及这个星球能够任何的一种通信协议，只要有我就可以快速的接入和使用。应用服务只需要做好自己的逻辑，不用理解前面连接状态，就可以实现双向的通信，并且可以灵活的支持各种加密，保证产品的安全性。