1 架构演进的定义
1.1 定义
通过设计新的系统架构(4R)，来应对业务和技术的发展变化。
1.2 关键点
新架构
新的复杂度
1.3 目的
应对业务和技术的发展变化后带来新的复杂度。
案例
淘宝去IOE，是因为业务发展大了后，IOE的成本和可控性难以满足，而非性能。
架构重构 vs 架构演进
技术手段不是区分架构重构和架构演进的方法，复杂度是否变化才是判断关键。
2 架构演进的原则、驱动力、模式
1个原则
架构演进是为了促进业务发展。
2个驱动力
业务发展带来新的复杂度，2C业务主要体现在用户规模增长和业务多样性。
技术发展带来新的复杂度应对方法，如国产化，大数据、云计算等。
2种模式
主动演进架构师主动识别和规划架构演进
被动演进: 架构师被迫进行架构演进。
3 业务驱动的架构演进技巧
3.1 架构演进模式 V.S 业务发展模式
主动演进
业务规模：量变带来质变，一般10倍量级变化才考虑架构演进。
业务多样性：业务规模可能没有变化，但系统支持的业务类型越来越多。
被动演进
业务方向：业务调整方向，例如从图文转为短视频。
3.2 不同用户规模的架构挑战
如果架构设计支持100万，但用户增长到200万时发现架构有问题怎么办？
优化、重构、演进。
3.3 业务驱动的主动演进技巧 - 做好预判，提前布局
预判
提前1年做好准备
以增长数字为标准：下一阶段用户规模60%时就要准备了
例如当前用户60万，下一级的典型用户规模是100万，那么就可以开始考虑架构演进了，别等到100万再演进
今年用户30万，老板说明年就要达到100万，今年就开始考虑架构演进
以时间为标准：提前1年预判
布局
团队和技术先行。
招聘人员
储备技术
3.4 业务驱动的被动演进技巧 - 快速响应，拿来主义
快速响应
熟悉什么就用什么
拿来主义
尽量用现成的方案
例如:
可能 Elasticsearch 更好，如果不熟悉，先用 MSQL 顶着
购买云服务的解决方案，例如直播、视频这种
尽量多用开源的方案
MySQL性能不如 Elasticsearch，用户体验不好咋办？
先跑起来！用户还不一定会用呢！毕竟若你不擅长的技术乱用，就更不稳定了。
演进案例
一开始 php+MySQL 快速试错，买的服务，后期改不动了。
4 技术驱动的架构演进技巧
4.1 技术驱动演进的第1原则 - 新瓶旧酒原则
新瓶旧酒原则：使用新的技术来解决老的问题或者老的复杂度，不要为了尝试新技术而演进。
降本
包括硬件、人力、运营等成本。
例如:
上云来降低运维和机房成本
去IOE，降低硬件成本
机器图片审核，降低审核人员成本
增效
提升效率包括处理、运营、开发运维效率等
例如 :
1.大数据平台提升大数据分析效率;
2.容器化提升运维效率:
3.微服务提升开发效率。
提质
提升质量包括业务、管理、开发等。例如 :
推荐系统提升用户转化率
容器化支持弹性扩容应对业务峰值
中台提升多业务的开发效率
技术驱动的架构演进是主动演进还是被动演进？
主动演进。问题很明显，就属于架构重构。而引入新技术是架构师自己决定的。
4.2 技术驱动演进的第2原则 - 价值原则
新技术要带来典型的价值，才考虑演进。
典型的定义：产出要＞＞投入
20台服务器降到10台 ? 2000台降到1500台?
2000人日降到1000人日 ?100人日降到10人日 ?
转换率提升2%? 用户留存提升10% ?
要直接计算出钱的多少。
4.3 技术驱动演进的技巧 - 如何说服老板进行演进？
技巧1 - 谈钱，别谈感情( 适合成熟技术 )
将引入新技术带来的价值量化成 money，然后附带说提升技术水平，提升团队动力不要本末倒置。
技巧2 - 谈竞争对手( 适合全新技术 )
如果你没办法量化为钱，那就看看竞争对手是否引入了，“吓晓吓晓”老板。
技巧3 - 谈大环境( 适合法律政治相关）
例如国产化，跟老板谈政治意义和大环境变化…
4.4 技术驱动演进的技巧 -做好洞察，提前布局
洞察：识别新技术能够为业务带来的价值
多关注业界技术大会
熟练掌握业务
把握技术本质
布局：团队和技术先行
招聘人员
储备技术
洞察”更难还是“预判”更难？洞察难得多！
案例
5 思维导图
6 测试
判断题
架构演进主要是为了引入新技术，跟上业界技术发展的趋势 ×
业务驱动的架构演进优先考虑“快速响应” × 被动演进才是
可以从成本、收益、竞争、法律法规等角度来阐述架构演进的必要性 √
技术驱动的架构演进一定要具备“降本、增效、提质”中的一或多个价值 √ 竞争对手做了或者国家法律要求，其实也都属于提质
“蚊子腿也是肉”，只要新技术能够带来一些价值，即使不那么大，也应该推进架构演进
关注业界技术大会+结合业务价值，就能拿到架构演进项目。
和领导谈钱
和下属谈情怀
大厂为了晋升，所以重复造轮子，适应大环境就好。
