微博绝对是现在使用用户数很大的了，在现在生活中基本处处都可以看到有人在看微博。
随着应用规模的不断增长，原始的微博架构已经不能满足现在的功能需求了，于是这一篇博客，就“新浪微博平台架构的演变”来探讨架构的性质。
第一代架构为LAMP架构，数据库使用的是MyIsam，后台用的是php，缓存为Memcache。
第二代架构对业务功能进行了模块化、服务化和组件化，后台系统从php替换为Java，逐渐形成SOA架构，在很长一段时间支撑了微博平台的业务发展。
在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。
微博平台的第三代技术体系，使用正交分解法建立模型：在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层；在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。
水平分层：
水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。
垂直延伸技术架构：
区别于水平方向上层依赖下层的关系，垂直方向以技术框架为地基支撑点，向两侧驱动影响业务架构、监控平台、服务治理平台。
垂直监控与服务治理：
1.用户通过浏览器或移动客户端的每一个HTTP请求到达应用服务器后，会经过很多个业务系统或系统组件，并留下足迹（footprint）。
2.收集每一处足迹的性能数据。
3.通过分析这些数据达到监控作用
服务层框架：
服务层主要涉及RPC远程调用框架以及消息队列框架：
消息队列提供一种先入先出的通讯机制，在平台内部，最常见的场景是将数据的落地操作异步写入队列，队列处理程序批量读取并写入DB，消息队列提供的异步机制加快了前端机的响应时间，其次，批量的DB操作也间接提高了DB操作性能，另外一个应用场景，平台通过消息队列，向搜索、大数据、商业运营部门提供实时数据。
总结：
1.技术框架在平台发挥越来越重要的作用，它能驱动着平台的技术升级、业务开发、系统运维服务。
2.架构的演变还是基于业务的，架构是围绕业务开展的
3.WatchMan由技术团队搭建框架，应用在所有业务场景中。
4.运维基于系统完善的监控平台，业务和运维共同使用此系统，完成分布式治理。
读完此篇文章之后，第一直观的感受是架构好复杂啊！有点蒙，自己最开始做系统的时候，基本上就是按照最基本的老师讲的套路来，很少去考虑这些基层的架构，也没有去考虑性能、兼容能问题，写过的系统很少能具体的投入使用，因为它还不具有真正适用的业务场景。所以在以后真正的系统开发时，更要花时间去考虑系统的架构设计，做一个实用的系统。
参考资料：