规划驱动架构和故障驱动架构

前言

在我看来架构驱动通常分为两种，规划驱动的和故障驱动。

前者更能体现出架构师在业务角度和技术角度的前瞻性能力，后者多是出现在业务高速发展阶段，大部分时间只能疲于应付吧。

比如在双十一我们经常听到因为流量过大造成服务瘫痪，系统不可用。

虽然我们通过建立可靠的上线，测试，部署流程。期望在测试及灰度阶段发现性能和可用性的潜在问题，但大部分还是难以避免线上的故障。

架构想要什么

架构的关键词：高可用，高并发，大数据，分布式，自动化。

故障驱动的架构师总是希望通过系统升级迭代，搞定那些线上暴露出的问题，修复他，对于那些还未发生，认为是不存在的。

当然大部分架构的发展是来自于业务需求，那我们是否还需要主动驱动架构？

架构不好预估，一般在大流量下我们才能更好的观察我们的系统能力。

“系统自动扩缩容”，“在流量不同时进行自动调整”听上去很赞，但是往往在黑天鹅来了之后还是哑火了，比如微博接入混合云后，号称自动扩缩容同时支持八对明星并发出轨，然后在鹿晗找了女朋友后就挂了。

规划系统

所以我们要明确的目标和将实施方案写进规划，讨论，落地，执行，折腾。

每次在分布式中间件，持续集成持续交付，DevOPS等折腾后，和行业内伙伴学习交流，关注发展历程和技术选型，将这些计入标准细节。每次都会有收获有启发。

建立破坏性故障演练，制定模拟场景，比如拔网线，丢包，IO不规则波动，消息堵塞等，去不断演练，坚固系统。