大家好，我是老马啸西风。
一位兴趣使然的技术开发者。
个人公众号
小于 1 分钟
内容概要
本系列文章是微博从服务化改造到 Service Mesh实践整个过程的分享（以微博自研 Service Mesh 解决方案 WeiboMesh 为例），主要是我们在这个过程中遇到的一些问题以及我个人关于服务化和 Service Mesh 的思考。
考虑到有的同学之前可能没有接触过 Service Mesh 这个概念，所以这里我先对 Service Mesh 做一个简单的介绍，作为后续内容的基础。
什么是 Service Mesh
Service Mesh 这个概念最早由开发 Linkerd 的 Buoyant, Inc 公司提出，2016年9月29日的 SF Microservices MeetUp 上他们的 CTO Oliver Gould 在关于微服务的分享中首次公开使用了这个术语。
大约 8 分钟
内容概要
技术支撑着业务高歌猛进，业务增长反过来又驱动着技术不断向前演化，这是每个互联网公司发展过程中不变的旋律。作为全国最大社交媒体网站的微博更是如此。
从 2009 年上线至今，微博架构经历了从最初的单体应用到后面的 RPC 服务化、容器化、混合云架构以及现在的跨语言服务化和 Service Mesh 等诸多阶段，架构演变支撑着微博业务的一次次华丽转身，也见证了微博的飞速成长。
那么，微博架构是如何从一开始的单体应用一步步成长为今天的庞大规模？作为国内最早落地 Service Mesh 的公司，微博为什么要选择做 Service Mesh，具体又是如何做的？这是本系列文章将试图回答的问题。
大约 12 分钟
内容概要
本文主要分析 WeiboMesh 在跨语言方面的探索。
第一篇文章我们梳理了 WeiboMesh 的演进历程。从单体应用到 RPC 服务化、容器化，到后期的混合云应用以及跨语言支持，再到目前的 WeiboMesh，Motan RPC 在其中扮演了至关重要的角色。
本文我将从 Motan 的服务治理和跨语言两个方面对 Motan RPC 做一个简单介绍。帮助大家更好地理解我们在 WeiboMesh 选型和落地过程中的一些取舍。
Motan RPC
Motan 从 2013 年上线至今，经历了无数次流量洪峰的检验，效果有目共睹。作为一个长于服务治理、轻量、具备良好扩展性、易于二次开发的高性能 RPC 框架， Motan 在微博的服务通信、微服务化拆分以及分布式服务治理等诸多场景中被大量使用。
大约 9 分钟
内容概要
本文主要分析 WeiboMesh 在 agent 方面的实现，如何结合各种注册中心来实现 WeiboMesh 的 agent。
前面我们谈到 WeiboMesh 源自我们对跨语言服务化的探索，最终我们通过在传输层和应用层之间增加对业务透明的 Mesh 层来解决大规模异构系统服务通信和治理的问题。
本文我将对这层抽象的核心基础设施层进行简要分析，希望能帮助你基于 WeiboMesh 对 Service Mesh 理念有一个更全面的理解。
水到渠成的 Service Mesh
在本系列文章的写作过程中，我详细调研并试用了业界几个重要的 Service Mesh 实现，发现大家基本都是在 2016 年开始做这个事情，由于都是在摸索中前进，所以实现的方式可能不尽相同，但思路和方向却出奇一致。
大约 8 分钟
内容概要
本文主要分析 WeiboMesh 在运行阶段请求路由的实现，对比现有的通用 Service Mesh （比如 Istio ）在这方面的不同。
前面我们对 WeiboMesh 的演化、实现以及 Service Mesh 规范等做了简要分析和解读，希望能帮助你基于 WeiboMesh 更好地理解 Service Mesh 的架构理念。
这里我们从实践的角度来体会下当前最受关注的 Service Mesh 实现 Istio 和 WeiboMesh 在服务调用和请求路由方面的一些异同，希望对你入坑 Service Mesh 有所帮助。
大约 13 分钟
内容概要
本文主要分析 WeiboMesh 在改造过程中对历史积累的一些考量以及适配，还有我个人对面向未来架构的思考。
从 SideCar 模式初具雏形的 2016 年末开始，WeiboMesh 就已经在生产环境逐步被摸索和打磨，并被大范围验证，这也是为什么 WeiboMesh 是目前最接地气的一个 Service Mesh 实现的原因所在。
它本身源自于微博内部对整体服务化的迫切需求，而面对微博巨大的流量和各业务线千差万别的异构服务现状，WeiboMesh 走出了一条适合自己也适合像微博这种在服务化进程中有着沉重历史包袱的团队。
大约 8 分钟
说起秒杀，我想你肯定不陌生，这两年，从双十一购物到春节抢红包，再到12306抢火车票，“秒杀”的场景处处可见。简单来说，秒杀就是在同一个时刻有大量的请求争抢购买同一个商品并完成交易的过程，用技术的行话来说就是大量的并发读和并发写。
大约 12 分钟
上一篇文章中，我介绍了秒杀系统在架构上要考虑的几个原则，我估计你很快就会问：“知易行难，这些原则应该怎么应用到系统中呢？”别急，从这篇文章开始，我就会逐一介绍秒杀系统的各个关键环节中涉及的关键技术。
大约 15 分钟
假设你的系统中存储有几十亿上百亿的商品，而每天有千万级的商品被上亿的用户访问，那么肯定有一部分被大量用户访问的热卖商品，这就是我们常说的“热点商品”。
这些热点商品中最极端的例子就是秒杀商品，它们在很短时间内被大量用户执行访问、添加购物车、下单等操作，这些操作我们就称为“热点操作”。那么问题来了：这些热点对系统有啥影响，我们非要关注这些热点吗？
大约 10 分钟