首先是开放的企业文化，自黑成传统，曾经因业务发展过快，服务器严重不足，微博上，员工一边自己黑公司、黑领导，同时大伙还不分昼夜反复调研、分析支撑数据，不断优化、改善系统架构，最后系统性能大幅提升，不仅满足了业务发展需要，服务稳定性也增加不少；

其次是积极向上的团队文化，平台内部每周、每月的技术分享，不同组之间通过项目横纵向合作，新技术也有充足的试验场；

最后，个人觉得在微博做研发是一个很有意义的事情，工作能养家，还能促进社会进步，不是挺好？跳槽可以认识大牛，微博可以自产更多大牛，不信到我们的首架群（微博出品的各厂首席架构师群）看看，哈哈。

　　CSDN：09年之后您就从事新浪微博的系统研发及架构工作，也经历新浪微博从起步到成为数亿用户的大型互联网系统的技术演进过程，可否分享下您对架构的理解？以及您对于架构师是如何定义的？他的能力，以及职责。

　　陈波：我个人对架构的理解是这样的：

　　从开发人员的角度，架构是系统整体结构的规划设计，也是系统实现的一个草图，atv，主要包含抽象出来的模块、交互协议及设计决策。因为架构的模块、协议、决策是抽象层面的规划，所以具体实现跟业务相关，要考虑业务的需求与特性，还跟业务发展阶段相关，要考虑业务当前的规模及发展阶段，选择合适的实现方案，必要时对当前的架构做适当的修改和演进。所以，架构是设计出来的，更是演进出来的；另外没有最好的架构，只有更适合（当前业务场景和阶段）的架构。

　　关于架构师如何定义：

　　架构师负责设计系统整体架构，确定系统实现的行动纲领，使设计的项目尽量高性能、高可用、易实现，并且在上线后运维方便，在新功能加入时扩展性良好。

　　架构师的能力要求：

较强的代码能力，对日常问题有丰富的阅历及解决之道，设计不是空谈，需要实践，代码能力、解决问题的能力是系统实践的一个副产品；

较好的抽象能力，业务需求在架构师消化后，需要转化为设计蓝图，这中间需要大量的抽象。

良好的沟通和组织能力，架构设计出来，需要组织讨论、频繁沟通，让项目组成员理解架构组成及设计取舍的原因，明白架构设计中的how和why，在遇到疑问、反对、建议时，能进行良好的沟通并有序的推进。

较好的团队协作能力和领导能力，架构师需要得到项目组成员的认可，在关键时刻对技术的选择作出及时、有效的决定，并为决定负责。

　　架构师的主要职责

把业务需求转换为实现架构，定义每个组成模块的外部特性，比如它的依赖、性能、异常处理等，并确定模块之间如何通信，最终形成可以指导业务开发的行动图。

组织讨论，组织更多的人来了解、讨论架构，能够让大家理解架构整体方案、模块特性及边界、决策权衡点，进而可以自行进行组件服务的设计及实现；

协助项目经理制定开发计划和控制项目进度；

确定系统的基础架构、实现技术，必要时组织技术调研和攻关。

　　CSDN：这几年的微博，有哪些技术架构的节点性事件？能否就各阶段从稳定性、可用性、性能、安全、监控等多方面来阐述快的高可用架构。

　　陈波：微博技术架构的节点性事件非常多。从feed分发策略上，有最初的推（push）模式，到后来的拉（pull）模式，到目前的hybrid（推拉结合）模式。从feed平台系统实现上，从最初的大一统实现结构，到11年的模块拆分，到13年构建motan RPC框架，进而14年开始服务的拆分、服务化，到目前基于混合云架构的微服务化。还有很多其他重要的节点性事件，如feed content存储及缓存结构从json／xml 改为更高效的protocol Buffer结构；首次在国内大规模使用和推广使用Redis；大数据处理引入Hadoop；系统部署采用混合云架构等等。

　　初期阶段，微博主要采用LAMP架构，feed采用push模式推送，存储放在MySQL，缓存采用memcached。这一阶段，微博用户快速增加，整体服务的稳定性不够，遇到突然事件或核心资源宕机时，可能会出现“暂时无法访问”的页面。此阶段，所有数据和请求在一个大的逻辑IDC，严重的缓存故障可能会导致DB被打满并雪崩，进而导致整个系统异常；因为运维人员不够，开发需要自行部署、切换服务，资源缺乏统一监控，容易出现故障；