新浪微博温情：基于微服务的微博直播互动架构设计经验分享

　　【讲师简介】

微博-研发中心平台高级系统研发工程师温情

温情，微博研发中心平台高级系统研发工程师，从事微博视频和通讯相关系统的研发。当前负责微博直播消息互动系统的研发。个人推崇高可用，可弹性伸缩，低耦合的微服务架构设计。技术上擅长消息通讯方向，针对系统应对突增流量和高并发方面有丰富的实践经验。

我们为什么需要微服务架构?

微服务(MicroServices)架构是当前互联网业界的一个技术热点，我们究竟为什么需要微服务架构?它能解决哪些问题?

对此，温情认为，微服务架构可以解决两大难题：

一方面，在一个系统功能比较单一的情况下，用单体式的方式进行开发部署是没有问题的，但是随着业务需求增多，复杂度增高，任何一次小需求的变更都需要进行打包上线、测试、部署，导致开发团队难以进行敏捷开发，每次添加新功能和修复bug都会变得非常耗时。一个应用越复杂，依赖的资源越多，启动速度越慢，难以实现快速扩展。

另一方面，随着开发人员越来越多，维护同一个应用，任何一个人的严重bug，例如内存泄漏等问题，都会导致整个服务不可用。

而微服务架构可以解决这些问题，所以微服务架构应运而生了。

微服务架构的优势与不足

事物的存在是具有两面性的，微服务架构也一样，存在着优势和不足。温情表示，微服务架构的优势与不足表现的都很明显。

优势在于：第一，通过服务划分的方式，解决了复杂性问题。第二，每个微服务独立开发，不同的开发团队可以用不同的语言，不同的技术实现。第三，每个微服务独立部署，独立扩展，减少服务之间依赖，同时不同服务的类型是不同的，有些是内存性，有些是CPU性，可根据服务类型选择不同类型的服务器。

不足在于：第一，相互依赖的服务之间的通信问题，可能会因为网络等因素而增加新的开销。第二，微服务拆分后，服务规模的增加，提高了运维的难度。第三，任何请求，在依赖的服务中都可能出错，排查问题的难度增加。

温情建议，虽然微服务架构有着很明显的优势，但是企业还需根据实际情况来考虑是否应用微服务。尤其在企业系统复杂度不高，业务不复杂的场景下，尽量还是用单体式开发。而千万不要为了“微服务”而强行进行微服务化。微服务不仅仅对开发人员提出了新的要求，同时也需要更加强大的运维团队支持。在系统复杂度不高的场景下，引入微服务，可能会成倍地增加维护的成本。同时也可能会引起难以快速响应需求，线上问题难以快速定位等问题。

微博直播互动微服务架构设计需要注意的那些细节

谈及微博直播互动微服务架构的设计，温情以目前正负责的微博识别消息互动系统的研发项目为例，对架构设计需要注意的细节等问题进行了深入的分析解读。

微博直播消息互动系统是一个相对比较复杂的系统，在设计上有很多特殊的需求。首先，在微服务化过程中，研发团队会比较注意核心服务和非核心服务的划分，从而在服务遇到瓶颈时，可以通过降级的方式保证核心业务不受影响。其次，对容易瓶颈的服务进行划分，减少对其他服务的依赖，使服务更加轻量化，从而实现服务快速扩展。第三，微博的服务常常会面临流量激增的问题，微博直播互动系统同样面临这样的问题，甚至激增的特性更加明显。在流量激增时，仅靠人工方式无法快速扩展服务，所以需要实现服务的自动化弹性伸缩。

微服务架构设计主要分为三个步骤：微服务的划分、微服务间的通信、微服务的部署。对设计的整个过程中的这三个环节中，有很多需要注意的细节。

对于微服务的划分，需要注意服务划分的粒度，切莫一开始就过于细粒度。而是根据服务和需求的的发展，在恰当的时候，对复杂度较高的服务进行拆分，将同一类功能的服务进行归类划分。举例来说，对于直播互动这个系统，服务的难点在于长期维护与用户的长连，并持续推送消息。一个10w人同时在线的房间，每秒有10个人评论，那推送的消息量将会是100w条/s。因此，推送服务也是最容易出现瓶颈和最需要快速扩容的服务。那么，在微服务划分时，需尽量地使推送服务轻量化，减少对其他服务的依赖，加快扩容速度。

对于微服务间的通信，需要注意的是服务依赖的问题。例如：一个服务A，它同步依赖的服务B平均耗时1s，这就会导致服务A的平均响应时间至少是1s。

对于微服务的部署，需要注意两点：一是，快速扩容时，依赖的资源和服务需要一起扩容，其中包括负载均衡、缓存，甚至是DB，否则服务仍会遇到瓶颈。二是，在升级服务时，依赖服务之间的上线问题。

WOT峰会演讲内容提前知