1 技术演进的方向
作为架构的实践者，必须及时跟进新的技术体系，同时需要慎重考虑引入新的内容，要想清楚新技术引入的必要性、能在短期带来的什么收益、能解决什么问题，同时还需要以观察者的角度来看业界大厂的实践，同时思考他们为什么要这么做，对于以后改进设计很有帮助
对于架构演进来说是有成本的，在准备改变之前要想明白的一个事就是这么做的成本是什么，会带来什么样的收益，当前的团队规模是否能稳定驾驭
需要跳出技术的范畴，从一个更广更高的角度来考虑这个问题：企业的业务发展。
影响一个企业业务的发展主要有 3 个因素：市场、技术、管理。这里探讨的是“技术”和“业务”之间的关系和互相如何影响。
企业的业务分为两类：一类是产品类，一类是服务类。
产品类：本质上和传统的制造业产品类似，都是具备了某种“功能”，单个用户通过购买或者免费使用这些产品来完成自己相关的某些任务，用户对这些产品是独占的。
服务类：大量用户使用这些服务来完成需要与其他人交互的任务，单个用户“使用”但不“独占”某个服务。事实上，服务的用户越多，服务的价值就越大。服务类的业务符合互联网的特征和本质：“互联”+“网”。
产品类业务大部分情况的演进：技术创新推动业务发展，因为用户选择一个产品的根本驱动力是“功能”
服务类业务的演进：业务发展推动技术发展，因为用户选择一个服务的根本驱动力是“规模”。
除非是创新的技术能够推动或者创造一种新的业务，其他情况下，都是业务的发展推动了技术的发展。
复杂度要么来源于功能不断叠加，要么来源于规模扩大，从而对性能和可用性有了更高的要求
无论什么模式的业务，如果业务的发展需要技术同步发展进行支撑，无一例外是因为业务“复杂度”的上升，导致原有的技术无法支撑，所以，对于架构师来说，判断业务当前和接下来一段时间的主要复杂度是什么就非常关键：是任何时候都要同时考虑功能复杂度和规模复杂度吗？还是有时候考虑功能复杂度，有时候考虑规模复杂度？还是随机挑一个复杂度的问题解决就可以了？
架构师需要基于业务发展阶段进行判断
2 互联网技术演进的模式
互联网业务的相同点：规模决定一切
互联网业务发展一般分为几个时期：初创期、发展期、竞争期、成熟期。
不同时期的差别主要体现在两个方面：复杂性、用户规模。
2.1 业务复杂性
1 初创期
需要快，但是这个时候却又是创业团队最弱小的时候
要有一个创新的业务点，快速迭代
2 发展期
要将原来不完善的业务逐渐完善，因此会有越来越多的新功能不断地加入到系统中。
这个阶段技术的核心工作是快速地实现各种需求，只有这样才能满足业务发展的需要。
阶段：堆功能期、优化期、架构期
3 竞争期
技术工作主要要解决重复造轮子、系统交互乱的问题
解决：平台化、服务化
4 成熟期
按照竞争的要求，找出自己的弱项，然后逐项优化。在逐项优化时，可以采取之前各个时期采用的手段。
2.1 用户规模
用户量增大对技术的影响主要体现在两个方面：性能要求越来越高、可用性要求越来越高。
想要提升性能，不可避免地要涉及到分布式，复杂性大幅度上升
想要提高可用性，不可避免地要涉及到冗余机器，复杂性也会上升
本质是“量变带来质变”
3 开源项目
演进的过程中，不可避免地要使用开源项目，那么如何选择、使用以及二次开发呢？
3.1 选
1 是否满足业务
这里的设计决策遵循架构设计原则中的“合适原则”和”演化原则”。
2 是否成熟
从这几个方面考察开源项目是否成熟：版本号、使用的公司数量、社区活跃度
3 运维能力
从这几个方面考察运维能力：开源项目日志是否齐全、开源项目是否有命令行、管理控制台等维护工具，能够看到系统运行时的情况、开源项目是否有故障检测和恢复的能力，例如告警、切换等
3.2 用
1 深入研究，仔细测试
- 通读开源项目的设计文档或者白皮书，了解其设计原理。
- 核对每个配置项的作用和影响，识别出关键配置项。
- 进行多种场景的性能测试。
- 进行压力测试，连续跑几天，观察 CPU、内存、磁盘 I/O 等指标波动。
- 进行故障测试：kill、断电、拔网线、重启 100 次以上、切换等。
2 小心应用，灰度发布
先在非核心的业务上用，然后有经验后慢慢扩展
3 做好应急，以防万一
做好备份
3.3 改
1 保持纯洁，加以包装
不要改动原系统，而是要开发辅助系统：监控、报警、负载均衡、管理等。
如果实在想改原有系统，建议是直接给开源项目提需求或者 bug，但弊端就是响应比较缓慢，这个就要看业务紧急程度了，如果实在太急那就只能自己改了；如果不是太急，建议做好备份或者应急手段即可。
2 发明你要的轮子
如果没有完全适合业务的轮子，且有钱有人有时间，那么投入人力去重复发明完美符合自己业务特点的轮子也是很好的选择