-
场景驱动： 一切脱离业务场景谈架构都是耍流氓。架构是根据业务复杂度、数据规模、团队能力、时间成本等因素进行折中的结果。 -
演进原则： 架构不是设计出来的，是演进出来的。遵循“降本增效”的目标。 -
设计哲学： “术（领域）不同，道相通”。
2. 互联网架构演进路径
A. 单体架构
-
定义： 客户端（App）直接请求一个包含所有业务逻辑的单体服务（WAR包），连接单一数据库。 -
优点： 开发、测试、部署、扩展初期都非常简单。 -
适用场景： 初创公司、O2O早期、对性能要求极高的金融场景。 -
破局： 当存储量和请求量过大时，通过垂直拆分 （分库）和水平拆分 （分表）来解决。
B. 面向服务架构 (SOA)
-
形态： 将单体拆分为多个垂直的业务服务（如房产服务、招聘服务）。 -
通信： 服务间通过ESB（企业服务总线）进行通信。 -
缺点： 仅仅是垂直维度的拆分，每个服务内部依然是单体，粒度较粗。
C. 水平分层架构
-
核心： 在垂直拆分的基础上，进行水平维度的分层。 分层结构： -
网关层： 负责负载均衡、路由。技术选型对比了Zuul, Spring Cloud Gateway, Nginx, Kong等（强调Nginx/Kong的高性能，Java系的易扩展）。 -
业务逻辑层： 聚合业务逻辑（如User Service, Trade Service）。 -
数据访问层： 屏蔽底层存储差异（RDBMS -> NoSQL -> NewSQL），负责CRUD和分库分表（Sharding-JDBC）。 通信模式： -
同步： RPC调用（Dubbo, Spring Boot）。 -
异步： 消息队列（提升吞吐量）。
D. 微服务架构 (Microservices)
-
定义： 一组小型服务，独立进程，轻量级通信。 -
形态： 业务垂直拆分 + 功能水平拆分。 痛点（微服务不是银弹）： -
业务代码中混杂了大量的“通信组件”代码（服务发现、熔断、限流、链路追踪等）。 -
基础设施升级困难（需要业务方配合升级SDK）。 -
多语言（Polyglot）支持成本高，每种语言都要维护一套基础设施SDK。
E. 服务网格架构 (Service Mesh)
-
核心目标： 将基础设施能力从应用程序中剥离下沉，实现业务逻辑与基础设施的物理/进程解耦 。 -
架构模式： Sidecar（边车）模式 。每个业务容器旁部署一个代理容器（如Envoy）。 组成： -
数据面板（Data Plane）： 智能代理（Sidecar），拦截并处理所有网络通信。 -
控制面板（Control Plane）： 管理代理，下发策略（如Istio）。
-
优势： 业务团队专注业务，基础设施团队独立迭代，天然支持多语言。
F. 中台架构 (Middle Platform)
-
背景： 解决微服务拆得过细导致的复用性问题，“分久必合”。 -
理念： 源自Supercell公司的“部落”文化。中台是支持多个前台业务且具备业务属性的共性能力组织 。 -
分类： 业务中台、数据中台、算法中台、技术中台。 -
数据存储设计： 采用“公共数据表（共性字段） + 业务个性化扩展表（Key-Value形式或扩展字段）”的方式，解决不同业务线的差异化需求。
G. 云原生架构
-
侧重： 运维侧。 -
关键词： DevOps、CI/CD、容器（Docker）、容器编排（Kubernetes）。
3. 真实案例演进：转转 (二手交易平台)
-
架构1.0： 初期的微服务，但粒度粗，业务逻辑耦合在同一个物理进程中。
-
架构2.0： 进行垂直拆分和水平分层。遇到的问题是SDK升级困难，业务服务由于包含大量非业务逻辑而变得臃肿。
架构3.0（大中台 + Service Mesh）： -
中台化： 抽象出公共逻辑层（发布、列表、详情、Push等服务）。 -
Service Mesh化： 引入Mesh解决基础设施侵入业务代码的问题，实现统一管理和流量控制。 
4. 总结归纳
-
架构设计维度： 单体 -> 水平分层 -> 面向服务 -> 微服务 -> 服务网格 -> 中台。 -
运维维度： 演进至云原生架构。 -
