今年6月6日晚上7点06分，一则林志玲微博上的闪婚消息，震撼了娱乐圈，更在微博社群引起轰动。这则婚讯发布不到3小时，经过网友疯狂转贴、评论，相关的讨论文章，在不到3小时内达到了45万则，浏览量更超过6亿次，立刻登上热搜榜第1位，尖峰时间甚至一度造成微博服务短暂瘫痪，之后几天，浏览人次更达到25亿次、89万则评论。就连原帖转发、评论也都超过数十万则以及数百万个赞。这一则短短不到50字的贴文，成为了微博IT团队维运的突发大挑战。
新浪微博研发总监李庆丰点出技术关键，在于打造一套高可用的微服务（Microservices）架构体系，并且搭配容器（Container）技术、分散式储存架构与混合云，才能做到支撑上亿用户每天内容发布需求，甚至遇到突发尖峰流量也不怕。
微博目前自建一套大型网络服务高可用架构体系，来提供上百服务、数亿用户消息发布的使用。该体系主要是由几大核心组件组成，并分4层，最上层是海量数据存储架构、接下来一层则是分布式缓存架构，微服务与容器化则是第3层，最底层则是备援用的多机房架构。整个架构外围还有搭配监控、服务治理、服务水准协议（SLA），来分别解决4大高可用性的挑战，也就是容量、性能、服务依赖，以及容灾问题。
微博是目前中国最大的微博的服务平台，用户只要通过订阅“关注”别人，就能看到对方发布的简短评论或内容，也可以说是中国版的推特（Twitter）；而且不仅能订阅内容，后来，该服务也加入了许多新功能，例如兴趣推送，或热搜功能等，持续增加用户黏着度，使得该服务使用人数逐年增长，光是最近短短4年，每月活跃用户就有翻倍增长，从2016年的2.82亿户，到了2019年第2季，增长更达到4.86亿户。
如今，微博全球多达2.1亿日活跃用户，单日评论、转发量超过数亿条，平均每日添加“关注”订阅数更达到上千万，更有上百个服务、多套系统同时运行，也成为微博IT团队首要面对的庞大IT考验。
微博目前自建一套超大型网络服务高可用架构体系，来提供每日数亿用户消息发布，与上百服务功能的使用。该体系主要是由多个重要核心组件组成，并分4层，最上层是海量数据存储架构，接下来一层则是分布式缓存架构，前2层都是用于数据存储与请求之用，微服务与容器化则是第3层，负责构建一个可灵活伸缩的弹性网络服务，还有最底层则是备援用的多机房架构。整个架构外围还有搭配监控、服务治理、服务水准协议（SLA），来分别解决4大高可用性的挑战，也就是容量、性能、服务依赖，以及容灾问题。
首先，是服务依赖的挑战。李庆丰表示，微博内容，从原本最简单的订阅发布模式，最近几年变得越来越复杂，因应用户数快速增，不只有各式各样的信息流模式，还有越来越多服务与新功能加入，累计至今已有上百个服务推出，例如发现、搜索、Feed流、串流直播等，这么多新服务，也导致服务相互之间依赖关系更复杂，需要有一个非常高度的服务治理能力，这也成为了微博IT所要面对的第一个技术挑战。
“我们解决服务依赖问题的关键，就是微服务与容器化。”他表示，微博服务之间容易存在高度依赖的原因，在于不论核心业务或非核心业务提供的Web服务，以往都放在同一个解析Java程序的Tomcat容器执行环境里，用来执行Web应用，尤其，早期的任务分组，每个核心团队同时要负责核心与非核心服务，并将这些服务执行程序部署在Web服务器里，所以，服务之间彼此相互关联非常紧密，只要这里面的其中一个非核心服务发生故障，也容易连带影响到另一个核心服务的正常运行。
不只同一团队里的个别服务，会有依赖问题，不同团队之间也会有相同问题。例如，当A团队负责的其中一个非核心服务发生异常，另一个B团队的核心服务，也容易受到牵连，因为通过http调用而向另一边A团队服务发送请求而产生间接依赖，严重甚至造成整个服务的中断，因此，就会产生很高的风险。
为了让各服务之间能够遵行高内聚，低耦合（high cohesion、low coupling）的原则，李庆丰表示，他们先是导入微服务架构，先将原本同一Tomcat容器里的不同服务拆分到各自独立的容器里，让不同服务都用个别容器来承接，以改善服务依赖情形。
不过，这样子的作法，也使得原先服务因为拆分造成架构变得更为复杂且庞大，进而衍伸出各服务调用效率及性能变差的情形。最后，他们是靠采用远程程序调用（Remote Procedure Call，RPC）机制来解决这个问题。
因为RPC的连接反应速度更快、调度、管理能力与自动化程度较高，李庆丰说明，比起一般http发送请求方式，更适合适于网络上不同服务之间的调用，甚至他们还因此开发出一个跨语言的RPC服务化框架，称为Motan，能通过RPC的方式，让服务之间的调用实现低延迟与改善性能问题。“这也是微服务化带来的问题之一，我们用RPC的方式来解决。”他说。
新浪微博研发总监李庆丰表示，微博服务背后的技术架构，在于打造一套高可用的微服务架构体系，及搭配容器、分布式存储架构与混合云，才能做到支撑上亿用户每天内容发布需求，甚至遇到突发尖峰流量也不怕。
另一个微服务带来的新挑战则是管理难题。李庆丰指出，微服务虽然解决了服务依赖耦合的问题，但也带来了运维复杂度的急剧增大，例如原先系统可能就只有4到5个服务之间存有依赖，运维管理相较简单，但是当单一应用服务拆成多个小型独立服务，服务拆分成越来越细，一次同时可能要维护管理上百个服务时，管理变得极为复杂，“甚至成为微博IT团队在服务运维上的一大噩梦，”他坦言，直到更轻量化的Docker容器的问世，才替他们解决了这个难题。
李庆丰说明，Docker容器的好处，不只在服务开发、运维两端可进行统一管理，也很容易隔离容器环境，还能协助IT团队缩短服务开发及上线时间，例如，原来100台传统服务器要部署完成并且推出上线得要花一整天，改采用容器后，平均每5分钟就能部署百台虚拟机从，24小时缩短到5分钟，足足快了将近290倍。
也因为采用了Docker部署方式，李庆丰指出，后来他们在打造混合云架构时，也更加容易许多，甚至当遇到重大政治、娱乐事件或重大节日带来的突发流量，无法单靠本地机房支撑时，就可通过这个架构迅速把流量导入到云计算。例如林志玲的结婚喜讯，短时间所带来的数亿级爆量发文，就需要采用这样的作法。
又如今年2月4日的央视春晚节目刚播出，不到几小时，微博贴文出现跟“春晚”有关的热门讨论，就超过一亿条、浏览人次更多达63.44亿次，以及50亿次短片播放，“对我们来说，这些不可预测的流量，需要做非常好的控制，但又要节省成本，”他指出，靠的就是利用Docker来打造一套弹性扩容系统，通过容器化方式快速部署，帮助他们更容易把容器化应用打包，放到公有云环境执行，使得在本地端和云计算之间调度服务变得更加弹性可伸缩，并且可以做到自动扩容的能力，来支撑微博春晚爆量消息发布的使用。“甚至，也帮助我们加快机器部署的准备时间，从原本1个月，现在只要3分钟就能完成。”他说。
他进一步归纳：“以微服务方式解决大量服务之间的耦合，并以容器化的方式改善微服务带来运维复杂度的问题，现在，更利用混合云架构降低运营成本，就是我们维持高可用性的解决方案。”这也是为何今年微博春晚出现尖峰流量，微博也能撑得住的关键，他补充说，这些都是创建在一定程度的资源监控体系之上，来打造一个可伸缩的弹性服务。
今年2月4日的央视春晚节目刚播出，不到几小时，微博上出现跟“春晚”有关的热门讨论，就超过一亿条、浏览人次更多达60亿次，但是微博IT团队却一点也不担心，靠的就是利用Docker容器与微服务来打造一套弹性扩容系统，使得在本地端和云计算之间资源调度变得更加弹性可伸缩，来支撑微博春晚爆量消息发布之用，甚至，也加快机器部署的准备时间，从原本1个月，缩短到3分钟完成。
除了超高尖峰流量的挑战，面对海量数据存储，对于微博现有的存储架构的考验同样不小，最直接反应在存储容量不够用，以致于数据存不下，请求扛不住，这也是第2大挑战。
但是想要存储更多数据，满足更大量请求，并不是增加存储容量就好，李庆丰特别强调事前准备的重要性，不论是从数据库选用，到实际测试，以及对于未来容量扩展的预测，都要事先做好完整规划，以决定最后该用哪一类型数据库，以及搭配多少台服务器。
以MySQL为例，他表示，在选用数据库前，会先考虑它的写入／读取性能，以及成本特性，作为选择存储组件的依据，还会实际在微博服务场景下通过测试看它在不同SSD、SAS硬盘上读写性能，避免一旦存储量用到极限，引起诸多安全问题。他也说，如果遇到的应用场景，需要存储量比较小，请求量较大时，就适用NoSQL数据库，如Redis等
选好存储组件，接下来，就进到容量规划，李庆丰指出，一般来说，容量规划会考虑几个问题，比如需要用多少台服务器，数据访问规模多大，存储容量才足够用。以微博的作法，还会将3个月后的用户使用情况、数据用量，以及1年后的服务增长规模纳入考量，同时，也会考虑存储成本、使用服务场景，以及在架构设计上，如何做到可扩展以及容错程度，他说，这些都是打造可扩展的数据存储架构必须考虑的事。
他也提到在实务上可能遇到的一些存储挑战，包括，读写比例的严重失调，单机容量瓶颈以及业务快速增长带来的容量问题。他指出，针对数据读多写少的情况，可以采用读写分离到不同的服务器分担，而要解决单机容量瓶颈，则是可采用水平拆分，将用户不同数据，以主／从的数据存储方式分别用不同服务器来存储，或是以垂直拆分方式，按时间维度进行拆分，存放在不同性能的服务器里。“尤其，微博的服务特性，让它更需要采用这样的作法。”李庆丰表示。
举例，微博一周以内发布的新内容，通常占所有服务读取请求的8成以上，但是一个月以前的内容，只占总请求的1成，因此，他表示，在这样情况下，就需要把老旧内容用更少的存储空间，搭配一般普通机器来承接，对于新的或比较热门数据，就可以放在新添购或性能更强的机器里，如此一来，用户的体验才会好。甚至，不只把这些内容依时间来做拆分，他补充说，还会将这些内容按月来区分，制作成分布分表，就能把一个月后请求量没那么大的内容，将它迁移到一些性能比较差的机器上，这也是微博打造海量数据存储的重要关键。
他提到第3个挑战则是性能问题。尤其是需要存储海量数据时，为了加快访问性能，微博还会搭配速度更快的缓存内存存储，构建一个分布式缓存架构，来打造一个可以提供高速访问的Web服务架构，李庆丰表示，这可以用来改善传统存储性能不够高的问题，并且通过创建分布式缓存架构，可以把这些缓存内存，依不同用户的请求指引到不同机器上，作法就跟分布式存储相似，比较不同的地方是，当一次要请求百人以上数据时，也容易因为拆分得太细而影响缓存性能。
因此，他们还进一步采用线性扩展方式，在数据缓存层的前面，额外加了一层缓存，称作L1缓存层，也就是针对多个请求量拆分时，不是按每一个数据模块来拆，而是以整组拆分的方式解决多人同时请求无法细拆数据分开存储的问题。
但李庆丰也直言，采用缓存比例越高，也容易加大系统复杂度与产生数据一致性问题，尤其，缓存是容量有限的内存，想要直接将数据存储在缓存中，虽然可以加快数据访问速度，但也将大幅提高成本，所以一般是将缓存存放一些最频繁使用的数据，又称为热数据（Hot Data），将这些存放在缓存里的热数据，拆成多分，并采用水平拆分方式，存储到不同机器上，借此解决了热数据存不下的问题；至于老旧数据或较没人看的冷数据（Cold Data），则放在一般硬盘里，以便于将有限缓存容量用在存储最热的内容。
另外，他也提醒，缓存用越多，一旦出现问题，也容易造成底层数据库的使用瓶颈，严重更会引起整个系统的宕机，因此，他建议在使用缓存架构时，必须创建一套主／备援（HA）机制，至少要能够设计成两层缓存，以便于当一个缓存层出现问题，备用的缓存层还可以快速接手，支撑这些服务请求，以避免大量请求直接穿过缓存进到数据库，一旦数据库撑不住，就容易导致整个系统大宕机。
最后一个挑战，则是确保服务维持不中断，李庆丰表示，关键在于采用多机房架构，以打造出容灾能力更强的IT运营架构。他指出，目前微博采行信息系统双活中心（multi-datacenter），将现有主要机房和异地备援用的机房，打造成一个同时并行的双主要机房，让同一套信息系统同时可以在两地运行，提供相同的服务，并且两边数据可以保持一致。一旦任一机房出问题，另一机房能马上接手提供原有的服务，也就达到了数据容灾的多机房。
不过，两地机房的数据同步，也会带来影响工作执行、同步延迟，以及数据丢失等问题。他表示，通常解决的方式，则是依据分布式系统的CAP理论，视业务场景不同，来决定要满足数据一致性（Consistency）、数据可用性（Availability），以及非区容忍性（Partition tolerance）三项中的哪两项要求。
不像电商、金融应用场景，对于数据一致性采取高标准，只要一有数据更新，所有节点上的数据在同一时间都要保持一致，李庆丰说，在微博社交场景下，对于数据一致性的要求就没有这么高，只需要确保两地数据最终保持一致就行，并通过MCQ这个数据同步组件，让异动数据与另一个机房对应的数据同步，来解决数据一致性的问题，发送请求也是相似作法。
除了采用更先进的技术架构，李庆丰也提出3个前提，来因应发生容量、性能、服务依赖，以及容灾4大问题的处理方式，首先是，“提前发现问题”，他指出，发现问题的方法有很多，可以通过事件监控，包含日志、监控仪表板、阈值报警、以及自动应变机制来完成；其次是“提前做好应对计划”，这些计划项目包含对于容错策略、服务扩容以及服务降级的紧急处置方案，以便于当有机器设备故障，可迅速找到问题机器将故障排除。当服务发生异常问题时，还需要依赖“上下游团队创建良好默契”的配合，这即是第3个前提，他说，这可以通过SLA服务协议创建一套指导原则的标准，例如机器性能达到什么情况下，会出现哪些问题，以及该如何解决等，并通过监控体系来支撑，还要能做到仿真演练，这也是构建高可用架构不可缺少的一环。
为了迎接更多新业务的挑战，微博近来也开始引进了近两年迅速窜红的Service Mesh（服务网格）技术，用来打造新一代高可用架构。并且一开始先用于创建标准化的服务治理，以及解决跨程序语言调用的问题。以服务治理来说，他表示，这样做的目的，是要将现有的服务基础治理架构，自业务逻辑层抽离放到基础设施里，形成Mesh形式的网格，让用户请求远程服务，都能像请求本地服务一样容易。
又如想要通过具有基础设施级别的本地Agent方式，如Motan、Restful、Yar、gRPC等来转换各程序语言之间调用的协议，以产生这种更方便调用的方式，他发现同样适合采行服务网格来完成，所以也用它来实例。
不论是服务治理或语言协议的转换，微博都已导入服务网格，“接下来，更要把服务调用，甚至缓存、存储、对链调用，都用这种网格架构来完成，让以后请求资源、服务就像请求本地的水和电一样简单。”李庆丰说。
为了迎接更多新业务的挑战，微博近来也开始引进了近两年迅速窜红的Service Mesh（服务网格）架构，打造新一代高可用架构。一开始先用于创建标准化的服务治理，以及解决跨程序语言调用的问题。接下来，更要把服务调用，甚至缓存、存储、对链调用，都用这种网格架构来完成，让以后请求资源、服务就像请求本地的水和电一样简单。