是我参与11月更文挑战的第23天，活动详情查看：2021最后一次更文挑战
了解互联网产品业务特点
业务特点
- 大流量、高并发：日活和并发远比传统企业应用高
- 高可用：对产品的不间断服务能力要求更加严格
- 海量数据：需要存储管理海量的业务、应用数据
- 用户分布范围广、网络环境复杂：产品服务的用户遍布全国，甚至海外，网络情况各异
- 产品演进迅速，发布频繁：产品演进快，更新频率快
了解互联网产品架构能力分析
架构能力
- 高性能：用户界面响应速度、接口延迟、吞吐率、资源利用率
- 高可用：系统不可用时间，衡量标注几个9，基本4个9
- 伸缩性：系统通过增加资源规模增强计算或事务处理能力（如扩容实例个数）。 即系统能够通过增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。如果这种增减是成比例的，酒杯称作线性伸缩性。在网站架构中，通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。
- 拓展性：增加新功能或系统变更时敏捷响应及对现有系统的**影响程度。**指对现有系统影响最小的情况下，系统功能可持续拓展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则（对扩展开放，对修改关闭），架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。
- 安全性：保护数据安全，应对现存和潜在的各自安全威胁
了解互联网产品架构演变历程
单体应用阶段
整体架构由单体应用构成，配合负载均衡提升可用性
优点
- 架构简单、易于理解、易于部署
- 同一个进程，强数据一致性
缺点
- 构建、编译、部署时间长
- 容易代码冲突，牵一发而动全身，即使修改了微小的功能，也有可能影响系统的全部功能，同时需要重发整个应用
- 伸缩性差，扩容成本高，部分功能如学习达到性能瓶颈，需要扩容整个主站
微服务拆分阶段
拆分单体应用、抽出共用功能为服务，独立部署，通过dubbo、spring cloud 进行服务间通信
优点
- 分层后架构清晰，修改或新增功能时不易对别的功能造成影响
- 分层后层之间更加稳定
缺点
- 分层架构的缺点依然存在，代码复用低，如垂直分层的应用都需要写一套用户服务
- 每个单体应用部署时间长、伸缩困难依旧没有解决
微服务完善阶段
完善微服务服务治理，进一步拆分优化单个服务
优点
- 单体应用分解为多个服务，每个服务独立开发、管理、运维，降低相互间的影响
- 提升伸缩性，可根据需要扩容部分服务
- 提升拓展性，基于服务实现拓展
缺点
- 系统架构变得复杂，难懂
- 测试部署困难，测试单个功能需要部署一系列服务
- 服务依赖复杂，无法快速感知系统情况
- 分布式部署带来的一系列问题
