系统架构演进路线及战术分析（微博、LinkedIn）

（课堂作业，仅作参考）

微博

微博，是基于用户关系的社交媒体平台，用户可以通过PC、手机等多种移动终端接入，以文字、图片、视频等多媒体形式，实现信息的即时分享、传播互动。微博基于公开平台架构，提供简单、前所未有的方式使用户能够公开实时发表内容，通过裂变式传播，让用户与他人互动并与世界紧密相连。

LAMP架构（2009年-2010年）。LAMP为微博的第一代平台架构，也就是平台为Linux，服务器为Apache（类似于Tomcat），数据库为MySQL，编程语言为PHP。在第一代架构中采用的是推消息模式，假如说一个明星用户他有10万个粉丝，那就是说明星发表一条微博的时候，我们把这个微博消息存成10万份，推送给每个用户。

在第一版的技术细节上，搜索引擎是使用MyISAM，它的优点就是速度非常快。另外一个是MPSS，使多个端口可以布置在同一服务器上，假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以有2种部署方式。我们可以把三个单元分别部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上。这个方法解决了两个问题，一个是负载均衡，另外一个是可以防止单点故障。
优点：
1）简单，易于实现，不需要额外的基础支撑。
2）利于业务的功能快速实现。
3）利于多业务并行开展，互不影响。
缺点：
1）随着用户数量越来越多，发表时会出现延迟现象，尤其是明星发表时，他的粉丝会等待很久才能看到。
2）由于系统处理明星时，占据大量服务，会影响到其他用户。
3）随着数据库容量增加，原来的单表模式，锁表的机制已经不再适用。

分布式平台化架构（2011年-2014年）。为应对极速增长的流量，应用规模的增长，衍生出的第二代架构，对业务功能进行了模块化、服务化和组件化，后台系统从PHP替换为Java，逐渐形成SOA（面向服务）架构，并构建了分布式缓存、千亿级存储、异地多活、监控、服务化等基础架构，改造完成后微博拥有了支撑亿级DAU（日活跃用户）、千亿级存储的高可用架构。并且业务更加集中，便于了推荐算法的更好实现。

微博在这一阶段主要需要面对日活用户1.6亿以上、平台接口日访问百亿级、核心记录千亿级、Cache内存百T级、Cache日访问万亿级、单个核心数据Cache QPS百万级等问题。微博构件了Feed平台系统。
Feed平台系统架构总共分为五层，最上面是端层，比如web端、客户端、大家用的IOS或安卓的一些客户端，还有一些开放平台、第三方接入的一些接口。下一层是平台接入层，不同的池子，主要是为了把好的资源集中调配给重要的核心接口，这样遇到突发流量的时候，就有更好的弹性来服务，提高服务稳定性。再下面是平台服务层，主要是Feed算法、关系等等。接下来是中间层，通过各种中间介质提供一些服务。最下面一层就是存储层。
在第三版技术细节上。开发了Feed Cache架构，它主要分为六层。首先第一层是Inbox，主要是分组的一些微博。然后对于第二层的Outbox，每个用户都会发常规的微博，都会在它的Outbox里。根据存的ID数量，实际上分成多个Cache，普通的大概是200多条，如果长的大概是2000条。第三层是一些关系，它的关注、粉丝、用户。第四层是内容，每一条微博的一些内容存在这里，等等。这样看来，用户一次请求得到的十几条记录，后端服务器大概要对几百甚至几千条数据进行实时组装，再返回给用户，整个过程对Cache体系强度依赖，所以Cache架构设计优劣会直接影响到微博体系表现的好坏。

在一些小的方面上，比如在投递模式上，把用户分成有效和无效的用户，比如一个明星发了微博，并不会把它推给所有的用户，而是首先推给像是今天登陆过的，或在线时间长的用户。在数据的拆分上，依据微博用户的一个特点就是实时性，所以将数据按照时间拆分，这样可以让数据库快速定位，降低了数据库的压力，并且还把内容和索引分开存放，使数据变的更容易扩展。在异步处理上，发表是一个非常繁重的操作，它要入库、统计索引、进入后台，如果要把所有的索引都做完用户需要等待很长的时间，如果有一个环节失败的话，用户得到的提示是发表失败，但是入库已经成功，这样会带来数据不一致问题，所以这个过程改成了异步操作，就是发表成功就提示成功，然后在后台等待消息队列慢慢的做完。
优点：
1）兼顾业务功能快速实现的同时保证了效果技术的不断深化。
2）提出以数据为先的思想，可以全面对比效果，推荐效果得以提升，给算法提供了很好的支持。
3）封层体系易于部署以及QA介入进行测试。
缺点：
1）对于算法的训练并没有涉及，仅仅是一个线上投放系统，不足以构成完整的推荐体系。
2）和推荐核心有一定的距离，并没有完全为推荐量身定做。

弹性混合云架构（2015年-2019年）：2015年起微博流量持续增长且热点频发，流量随时都可能成倍增加。为在可控的成本下完成热点应对工作，微博研发团队构建了基于Docker和公有云的弹性混合云架构，从核心业务开始花了三四年的时间逐步推广到微博各个业务，最终让各主要业务都具备了极速扩容能力，最新的弹性扩容速度是10分钟5000台。同时，也完成了微博的热点联动机制和 Service Mesh技术架构WeiboMesh（类似Nginx）的建设，并推广到了各业务。
在第三版技术细节上，采用了微服务治理的策略。WeiboMesh把服务间的交互与治理逻辑从业务中进行解耦，抽象独立成一个专门的处理模块，Agent可以理解为服务的基础设施层，业务无需关心服务间交互/治理细节，全部交由Agent统一处理。WeiboMesh带来的是微服务架构思路的转变，为业务开发带来了诸多架构上的优势，实现了服务发现、交互、路由、治理等功能。

为了实现大规模的节点扩容能力，从2014年开始，新浪微博做单机容器化和在线Docker集群。2015年，基于Docker的思维做弹性调度、服务发现与私有云建设。2016年，开始做混合云的部署。DCP架构底层私有云采用的是基于OpenStack，公有云是和阿里云合作。整个架构从上到下分为编排、调度和主机三层。当流量来临时，主机层通过私有云和公有云的SDK进行主机的创建，之后做初始化达到快速上线的目的。初始化主要做运维环境和Docker环境的安装。初始化之后，编程可运行 Docker 环境，在经过容器调度和服务编排之后，会自动被服务发现模块引入流量，进行上线。

优点：
1）解决了热点、突发事件所引发流量洪峰的应对。
2）提升了混合云微服务架构下的复杂拓扑带来的冗长的调用链路、低效的请求长尾与及其复杂的故障排查。
解决了各语言服务治理能力差异性引入的异构系统服务治理体系建设难题。

智能云原生架构（2020年至今）：随着弹性能力的提升，微博单个运维和DBA（数据库管理员）能保障的服务和资源规模大幅增加，微博DBA人均管理1万以上的资源端口，但随着架构复杂度不断提升，如何提供普遍的高品质的保障服务变成新的挑战。研发团队开始对数据库、缓存、消息队列等进行智能化和弹性调度改造，并完成了可将单位成本降低50%的基于阿里云高配神龙服务器的整租零售方案建设，同时也在将运维和DBA团队升级为DevOps（强调开发测试部署运维一起做）团队。由于云原生架构的改造和建设工作量非常巨大，相关工作还在持续推进中。

主要参考

1.https://itindex.net/detail/54525-%E5%BE%AE%E5%8D%9A-%E6%9E%B6%E6%9E%84
2.https://developer.aliyun.com/article/356043
3.https://www.sohu.com/a/464186489_355140
4.https://www.techug.com/post/weibo-cache-design.html
5.https://www.sohu.com/a/158384566_463994
https://zhuanlan.zhihu.com/p/58221795

中文名“领英”，启动于2003年5月，是一个面向职场的社交平台，网站的目的是让注册用户维护他们在商业交往中认识并信任的联系人，俗称“人脉”。用户可以邀请他认识的人成为“关系”圈的人。截至2020年5月，领英的用户总量已经达到6.9亿以上，在中国拥有超过5000万名用户。
在早起刚刚起步，只有几千用户，和现在很多站点开始的时候一样， LinkedIn使用一个应用程序做所有的工作。这个应用程序被称之为 “Leo”。它包含所有的Java Servle页面，处理业务逻辑，连接少量的数据库。

随着站点的增长，Leo系统也在扩大，增加了更多的角色和职能，也更加复杂。通过负载均衡可以运行多个Leo实例，但是新增的负载也影响到LinkedIn的最关键系统会员信息数据库。为了扩展，团队引入了复制从库(replica slave DB)。复制数据库是会员数据库的一个拷贝，使用databus（分布式数据库同步系统）来进行同步。这些复制从库处理所有的读请求，并且增加了保证主库和从库数据一致性的逻辑。

当站点遇到越来越多的流量时，单一的Leo系统经常宕机，而且很难排查和恢复，发布新代码也很困难。为了高可用性需要拆掉Leo，把它分解成多个小的功能模块和无状态的服务。最开始抽取出一些微服务，这些微服务提供API和一些业务逻辑，如搜索，会员信息，通讯和群组平台。接着表现层也被抽取出来了，比如招聘产品和公共信息页。新产品，新服务都独立于Leo。团队构建了前端服务器，可以从不同的域获取数据，处理展示逻辑以及生成HTML。团队还构建了中间层服务提供API接口访问数据模型以及提供数据库一致性访问后端数据服务。因为无状态，规模扩展可以通过堆叠任意服务的新实例以及在它们之间进行负载均衡来完成。并且给每个服务设定了警戒红线，知道它的负载能力，提供早期预警和性能监控。并且为了减少负载压力，添加了更多的缓存层，很多应用开始引入中间缓存层如 memecached 或者 couchbase（类似于Redis）。

随着网站还在壮大，有了更多的定制管道。因为网站规模需要扩展，每一个独立的管道也需要扩展。Kafka成为一个统一的管道，它是LinkedIn的分布式的发布订阅消息系统，根据commit log的概念构建, 特别注重速度和扩展性。它可以接近实时的访问数据源，驱动Hadoop任务，允许构建实时的分析，广泛地提升了站点的监控和报警能力。

当LinkedIn从Leo转向面向服务的架构后，之前抽取的基于Java RPC的API, 在团队中开始变得不一致，表现层耦合太紧。为了解决这个问题，团队开发了一个新的API模型，叫做 Rest.li（微服务架构）。Rest.li符合面向数据模型的架构，确保在整个公司提供一致性的无状态的Restful API模型。基于HTTP的JSON数据，新的API最终很容易地编写非Java的客户端。LinkedIn今天仍然主要使用Java栈，但是也有很多使用Python，Ruby，Node.js和C++的客户端。脱离了RPC，实现微服务后，也让使得兼容型的问题得以解决。

主要参考

1.https://colobu.com/2015/07/24/brief-history-scaling-linkedin/
2.https://mp.weixin.qq.com/s?__biz=MzU1NDA4NjU2MA==&mid=2247486499&idx=1&sn=8535dab999b32ed4b34192fbb94ab224&source=41&scene=21#wechat_redirect