架构实践05-互联网架构模板

零、文章目录

架构实践05-互联网架构模板

1、技术演进的方向

（1）技术演进的方向判断

• 潮流派：热衷于新技术，紧跟技术潮流，但可能面临技术不成熟的风险和学习成本。
• 保守派：强调稳定，对新技术持戒备态度，可能会错失新技术带来的巨大收益。
• 跟风派：跟随竞争对手的技术选择，但可能存在信息不对称和适用性问题。

（2）技术演进的动力

• 业务发展：市场、技术和管理是支撑业务发展的三个关键因素。
• 产品类业务：技术创新推动业务发展，用户选择产品的驱动力在于功能、性能、体验等。
• 服务类业务：业务发展推动技术发展，用户选择服务的驱动力在于规模，而非功能。

（3）技术演进的模式

• 复杂度变化：业务复杂度的变化是技术演进的主要驱动力，复杂度来源包括功能叠加和规模扩大。
• 业务发展阶段：架构师需要根据业务的发展阶段来判断主要复杂度，从而做出合理的技术决策。

（4）架构设计的演进原则

• 逐步演进：架构设计不是一步到位的，需要根据业务的发展逐步演进。
• 参考与借鉴：可以参考成熟企业的架构演进路径，但需结合自身业务特点进行调整。
• 大公司与小公司：大公司可以从较高的起点（如60分）开始演进，小公司则可以从较低的起点（如20分）开始演进。

（5）实际案例

• 淘宝：从最初的PHP系统到Oracle数据库，再到Java替换PHP，逐步解决了性能、稳定性和系统耦合等问题。
• 银行IT系统：从90年代的功能复杂度到2004年后的性能和安全复杂度，再到2009年后的移动支付复杂度，逐步演进。

2、技术演进的模式

（1）业务发展阶段

• 互联网业务的发展可以分为四个主要阶段：初创期、发展期、竞争期和成熟期。

（2）业务复杂性

• 初创期：重点在于"创新"，系统相对简单，快速迭代试错。

• 发展期：业务逐渐完善，功能不断增加，系统开始变得复杂。
• 竞争期：业务进一步完善，系统拆分增多，技术要求更高。
• 成熟期：业务创新机会减少，注重"求精"，优化细节。

（3）用户规模

• 初创期：用户量较少，技术要求较低。
• 发展期：用户量增加，性能和可用性要求提高。
• 竞争期：用户量大幅增加，系统复杂度和可用性要求更高。
• 成熟期：用户量稳定，注重高性能和高可用性。

（4）技术演进路径

• 初创期：快速开发，使用开源工具和现成解决方案。
• 发展期：快速实现需求，逐步优化和重构。
• 竞争期：系统拆分，平台化和服务化。
• 成熟期：持续优化，提升性能和可用性。

（5）关键技术手段

• 优化：通过重构、分层、优化查询、更换硬件等手段提升性能。
• 架构调整：将大系统拆分为多个小系统，提高扩展性和维护性。
• 平台化：解决重复造轮子的问题，如存储平台化、数据库平台化、缓存平台化。
• 服务化：通过消息队列和服务框架解决系统间交互问题。

（6）量变到质变

• 性能：用户量增加导致性能要求提高，从集中式存储变为分布式存储。
• 可用性：用户量增加导致可用性要求提高，宕机的影响显著增大。

3、互联网架构模板：存储层技术

（1）技术架构的共通性

• BAT及其他互联网公司：虽然业务差异大，但技术架构基本相同，最终殊途同归。
• 技术发展：业务的不断发展推动了技术的发展，经过多年积累达到当前的复杂度和先进性。

（2）存储层技术概述

• SQL（关系数据库）：
  • 特点：开源免费，性能相对较差。
  • 解决方案：数据库拆分、中间件（如DBProxy、TDDL）、SQL存储平台（如UMP）。
  • 挑战：性能要求高，数据拆分和组合复杂。
• NoSQL（非关系数据库）：
  • 特点：数据结构多样，性能优越。
  • 应用场景：补充关系数据库，广泛应用于互联网行业。
  • 解决方案：集群功能、NoSQL存储平台（如Memcache、Redis）。
  • 挑战：大规模应用时需要集中管理和资源优化。
• 小文件存储：
  • 特点：数据小、数量巨大、访问量大。
  • 解决方案：统一的小文件存储平台（如TFS、JFS、Haystack）。
  • 优势：提高效率，避免重复造轮子。

• 大文件存储：
  • 特点：文件大、数量相对较少。
  • 应用场景：业务大数据、日志数据。
  • 解决方案：Hadoop生态（如HDFS、HBase）、大数据平台（如云梯、TDW）。
  • 挑战：存储和处理方式与小文件不同，需要专门的存储系统。

（3）存储平台的发展

• 存储平台的必要性：
  • 资源管理：提高资源利用率，减少维护成本。
  • 自动化：故障自动处理，资源动态分配。
  • 适用场景：大公司通常会构建存储平台，中小公司则倾向于使用开源方案或云存储。
• 为何没有开源存储平台：
  • 开发成本高：需要经验丰富的高级工程师。
  • 需求量少：只有大型公司才有需求，小公司业务规模不大。
  • 云存储的普及：云存储提供了低成本、高性能的解决方案，减少了自建存储平台的必要性。

4、互联网架构模板：开发层技术

（1）开发框架

• 定义与作用
  • 开发框架是指用于简化软件开发过程的一组工具和库。它们提供了标准的结构和方法，帮助开发者快速构建应用程序。
  • 作用：提高开发效率，减少重复代码，统一开发标准，便于团队协作。
• 选择原则
  • 成熟性：优先选择成熟的框架，因为这些框架通常文档齐全，社区活跃，遇到问题容易找到解决方案。
  • 稳定性：成熟的框架更加稳定，不会频繁变动，适合长期发展。
  • 招聘便利性：成熟的框架受众广泛，招聘时更容易找到熟悉该框架的开发者。
• 常见框架
  • Java：SSH（Struts + Spring + Hibernate）、SpringMVC、Play
  • Ruby：Ruby on Rails
  • PHP：ThinkPHP
  • Python：Django
• 案例
  • 阿里巴巴：使用 Spring 框架作为主要的开发框架。
  • 腾讯：使用 SpringMVC 和 MyBatis 结合的开发框架。

（2）Web 服务器

• 定义与作用
  • Web 服务器是用于接收客户端请求并返回响应的软件。它是连接前端和后端的关键桥梁。
  • 作用：处理 HTTP 请求，提供静态和动态内容，管理会话，负载均衡等。
• 选择原则
  • 成熟性：选择成熟的开源 Web 服务器，因为它们经过了广泛的测试和优化。
  • 性能：根据业务需求选择性能合适的服务器。
  • 易用性：选择易于配置和维护的服务器。
• 常见服务器
  • Java：Tomcat、JBoss、Resin
  • PHP/Python：Nginx
  • 通用：Apache（支持多种语言）
• 案例
  • 淘宝：使用 Tengine（基于 Nginx 的定制版）作为主要的 Web 服务器。
  • 百度：使用 Apache 作为主要的 Web 服务器。

（3）容器技术

• 定义与作用
  • 容器技术是一种轻量级的虚拟化技术，用于将应用程序及其依赖打包在一起，使其在不同的环境中能够一致地运行。
  • 作用：提高资源利用率，加快部署速度，简化运维管理。
• 常见容器技术
  • Docker：最流行的容器技术之一，以其轻量、快速启动和资源占用少而著称。
  • Kubernetes：用于管理和编排 Docker 容器的平台，提供自动化的部署、扩展和管理功能。
• 优势
  • 快速启动：容器启动速度快，几乎不占用额外资源。
  • 隔离性：容器之间相互隔离，互不影响。
  • 一致性：在不同环境中保持一致的行为。
• 案例
  • 腾讯：万台规模的 Docker 应用实践。
  • 新浪微博：大规模 Docker 集群的实践经验。

5、 互联网架构模板：服务层技术

（1）配置中心

• 定义：配置中心是集中管理各个系统配置的工具。
• 问题 ：
  • 当系统数量不多时，各系统自己管理配置。
  • 系统数量增加后，分散管理配置会导致配置错误、沟通协调困难等问题。
• 解决方案 ：
  • 集中管理：将所有系统的配置集中管理，减少配置错误。
  • 快速恢复：当系统出现故障时，可以通过配置中心快速恢复环境。
  • 规则检查：配置中心可以实现程序化的规则检查，避免常见的配置错误。
• 设计 ：
  • 通过"系统标识 + host + port"来标识唯一一个系统运行实例。
  • 提供配置推送、定时校验等机制，确保配置的及时更新。

（2）服务中心

• 解决跨系统依赖：服务中心解决系统间依赖的"配置"和"调度"问题，减少系统间的协调工作量。
• 实现方式：服务名字系统和服务总线系统，前者类似DNS，后者由总线系统完成调用。

（3）消息队列

• 异步通知：消息队列实现跨系统的异步通知，简化系统间交互，提高系统性能和可用性。
• 功能特点：消息队列可以实现"一对一"和"一对多"通知，支持高性能、高可用、消息时序性和事务性。
• 

6、互联网架构模板：网络层技术

（1）负载均衡

• DNS
  • 优点：通用、成本低
  • 缺点：缓存时间长、不够灵活
  • 应用场景：地理级别的负载均衡
• HTTP-DNS
  • 优点：灵活、可控
  • 缺点：开发成本高、侵入性
  • 应用场景：App 提供的服务
• Nginx、LVS、F5
  • Nginx：软件的 7 层负载均衡，性能万级
  • LVS：内核的 4 层负载均衡，性能十万级
  • F5：硬件的 4 层负载均衡，性能百万级
  • 应用场景：同一地点内机器级别的负载均衡

（2）CDN（内容分发网络）

• CDN 通过将内容缓存在离用户最近的地方，减少网络延迟，提高访问速度。
• 请求流程：用户请求 -> CDN 节点 -> 原站
• 应用场景：视频、直播等领域

（3）多机房

• 多机房设计旨在提高系统的高可用性，防止单机房故障导致业务中断。
• 同城多机房：通过私有高速网络实现低时延
• 跨城多机房：通过数据复制实现最终一致性
• 跨国多机房：主要用于备份和服务本国用户

（4）多中心

• 多中心设计在多机房的基础上进一步提升系统的高可用性和容灾能力。
• 设计目标：每个中心同时对外提供服务，自动切换，故障后自动恢复
• 关键技术：数据一致性、数据事务性
• 挑战：复杂性高，需要基于业务特性进行详细设计

7、互联网架构模板：用户层技术

（1）用户管理

• 单点登录（SSO）：实现用户在多个子系统中的统一登录，常用技术包括 cookie、JSONP、token 等，开源方案如 CAS。

• 授权登录：允许第三方应用接入，常用协议为 OAuth 2.0。
• 用户数据管理：虽然用户数据量巨大，但由于用户之间业务关联性弱，可以通过简单的负载均衡架构应对。

（2）消息推送

• 途径：短信、邮件、站内信、App 推送。
• 技术挑战：
  • 设备管理：管理大量设备，将用户和设备关联起来。
  • 连接保活：保持连接通道，防止因设备限制导致消息无法送达。
  • 消息管理：根据用户特征选择推送对象，设计灵活的消息推送逻辑。

（3）存储云、图片云

• 特点：数据量大、文件体积小、访问有时效性。
• 实现：通常采用"CDN + 小文件存储"技术，图片云额外支持裁剪、压缩、美化等功能。
• 建议：除非大型企业，一般推荐购买云服务。

8、互联网架构模板：业务层技术

（1）复杂度管理

• 系统拆分：将整体复杂性分散到多个子业务或子系统，常见方法有分层架构、微服务、微内核等。
• 虚拟业务域：将职责关联性强的子系统合成一个虚拟业务域，通过网关对外统一呈现，类似于设计模式中的 Facade 模式。

（2）电商系统示例

• 第一阶段：所有功能在一个系统中。
• 第二阶段：拆分为商品和订单两个子系统。
• 第三阶段：进一步拆分为更小的子系统。

（3）虚拟业务域的划分

• 粒度：建议粗一些，通常控制在 3 到 7 个。
• 原因：避免系统拆分过细导致的复杂度问题，便于管理和维护。

9、互联网架构模板：平台层技术

（1）运维平台

• 核心职责：配置、部署、监控、应急
• 设计要素：标准化、平台化、自动化、可视化
  • 标准化：制定运维标准，规范配置管理、部署流程、监控指标、应急能力等。
  • 平台化：将运维操作集成到平台中，提高效率和准确性。
  • 自动化：减少重复操作，提高部署、监控等环节的效率。
  • 可视化：通过图形界面提升数据查看效率，便于快速定位问题。

（2）测试平台

• 核心职责：单元测试、集成测试、接口测试、性能测试
• 设计关键：自动化
  • 用例管理：管理测试用例，包括业务、系统、测试类型、用例代码等。
  • 资源管理：管理测试环境的硬件、软件、业务系统等资源。
  • 任务管理：分配测试用例到资源上执行，跟踪任务执行情况。
  • 数据管理：记录测试结果及相关数据，用于后续分析和对比。

（3）数据平台

• 核心职责：数据管理、数据分析、数据应用
  • 数据管理：数据采集、数据存储、数据访问、数据安全。
  • 数据分析：数据统计、数据挖掘、机器学习、深度学习。
  • 数据应用：在线业务（如推荐、广告）和离线业务（如报表、欺诈检测、异常检测）。

（4）管理平台

• 核心职责：权限管理
  • 身份认证：确定操作人员身份，防止非法人员进入系统。
  • 权限控制：根据操作人员身份确定操作权限，防止未经授权的人员进行操作。

（5）平台开发团队的选择

• 中间件团队开发：
  • 优点：平台架构有保障，代码质量高，开发效率高。
  • 缺点：前期业务沟通成本大，功能性需求的易用性和响应速度可能较差。
  • 适用场景：运维和测试开发能力较弱的小公司。
• 运维和测试团队自己开发：
  • 优点：更贴近实际需求，功能完善，易用性好。
  • 缺点：开发效率低，平台性能和可靠性可能较差。
  • 适用场景：运维和测试团队技术能力强，有足够时间和资源的大公司。

10、架构重构 1：识别核心问题

（1）架构重构的必要性和挑战

• 业务已上线：架构重构时业务已经在运行，需要在不影响业务的前提下完成架构调整。
• 关联方众多：涉及多个业务关联方，需要协调各方资源和行动。
• 技术选择受限：在旧架构基础上进行重构，技术选择范围受限。
• 数据迁移：新架构需要考虑如何将旧架构产生的数据转换过来。

（2）架构重构的难度

• 综合能力要求高：架构师需要具备业务沟通、团队协调和技术攻关等多方面的能力。
• 识别核心问题：从众多问题中识别出真正需要通过架构重构解决的核心问题。
• 避免全面重构：集中力量解决关键问题，而不是试图解决所有问题。

（3）重构策略

• 识别核心问题：透过问题表象看到本质，找出真正需要通过架构重构解决的问题。
• 避免过度重构：不要试图通过架构重构解决所有问题，集中力量解决关键问题。
• 逐步优化：在重构完成后，可以通过多个优化项目来解决其他问题。

（4）实践建议

• 评估重构必要性：假设从零开始设计当前系统，如果新架构和老架构差异不大，说明采取系统优化即可；如果差异很大，可能需要进行系统重构。
• 协调资源：在重构过程中，需要协调各方资源，确保业务正常发展。
• 逐步实施：逐步进行重构，避免一次性大动作导致业务中断。

（5）案例：后台系统重构：解决不合理的耦合

• 背景 ：
  • 系统名称：M 系统
  • 功能：负责管理所有游戏相关的数据
  • 问题：系统耦合了 P 业务独有的数据和所有业务公用的数据，导致可扩展性较差。
  • 架构图：数据库中的某张表，一部分字段是所有业务公用的"游戏数据"，一部分字段是 P 业务系统"独有的数据"。
• 重构目标 ：
  • 解耦：将游戏数据和业务数据拆分，解开两者的耦合，使得两个系统能够独立快速发展。
  • 重构方案：
  • 拆分数据：将公用数据和业务独有数据分别存储在不同的表中。
  • 独立系统：将 M 系统和 P 业务后台系统拆分为两个独立的系统，每个系统有自己的数据库和业务逻辑。
• 效果 ：
  • 提升开发效率：重构后的 M 系统和 P 业务后台系统每月上线版本数是重构前的 4 倍。

（6）案例：游戏接入系统重构：解决全局单点的可用性问题

• 背景 ：
  • 系统名称：S 系统
  • 功能：游戏接入的核心系统，负责玩家登录等核心功能
  • 问题：S 系统不具备多中心的能力，一旦主机房宕机，整个 S 系统业务就不可用。
  • 架构图：数据库主库是全局单点，一旦数据库主库不可用，两个集群的写业务都不可用。
• 重构目标 ：
  • 实现双中心：使得任意一个机房都能够提供完整的服务，在某个机房故障时，另一个机房能够全部接管所有业务。
  • 重构方案：
  • 多中心部署：在两个机房部署相同的系统，通过数据同步机制保证数据一致性。
  • 负载均衡：使用负载均衡器将请求分发到两个机房，确保高可用性。
• 效果 ：
  • 提升可用性：系统可用性从 3 个 9 提升到 4 个 9。
  • 减少故障影响：重构后，尽管经历了机房交换机宕机、运营商线路故障、机柜断电等问题，但对业务没有太大影响。

（7）案例： X 系统：解决大系统带来的开发效率问题

• 背景 ：
  • 系统名称：X 系统
  • 功能：创新业务的主系统
  • 问题：系统设计初期为了快速试错，将所有功能都"塞"到同一个系统中，导致系统复杂度高，开发效率低。
  • 架构图：所有功能都在同一个系统中，修改一个功能可能影响整个系统的稳定性。
• 重构目标 ：
  • 拆分功能：将各个功能拆分到不同的子系统中，降低单个系统的复杂度。
• 重构方案 ：
  • 微服务化：将大系统拆分为多个独立的子系统，每个子系统负责特定的功能。
  • 接口交互：子系统之间通过接口进行通信，确保各系统的独立性和可扩展性。
• 效果 ：
  • 提升开发效率：各系统的开发和上线速度比原来快了很多。
  • 降低故障影响：即使某个子系统出现问题，也不会影响其他子系统的正常运行。

11、架构重构 2：注重沟通

（1）架构重构的重要性

• 持续时间和资源占用：架构重构是一个长期过程，会占用大量研发资源，包括开发和测试。
• 影响业务功能：重构过程中可能会对业务功能的开发产生影响，因此需要谨慎推进。

（2）合纵

• 沟通和游说：推动架构重构需要大量的沟通和游说工作，以获得利益相关方的支持。
• 避免技术术语：与非技术人员沟通时，应避免使用过多的技术术语，转而使用通俗易懂的语言。
• 数据和事实：以数据和事实为依据，展示重构的必要性和预期收益，更容易说服相关人员。

（3）连横

• 跨系统沟通：重构项目往往需要与其他相关系统的团队进行沟通和协调。
• 换位思考：站在对方的角度思考，了解他们的需求和顾虑，寻找合作双赢的方案。
• 关注长期利益：强调重构的长期收益，而非短期的不便或工作量增加。
• 灵活应对：根据实际情况灵活调整计划和方案，确保各方都能接受。

（4）沟通和推动的角色

• 架构师的职责：架构师不仅需要具备技术能力，还需要具备良好的沟通和推动能力。
• 项目经理的角色：项目经理主要负责项目的整体进度，可能对重构持保守态度。
• 合作与分工：架构师和项目经理在重构项目中应密切合作，各自发挥优势，共同推动项目的顺利进行。

（5）实际案例

• M 系统：通过具体的数据和实例，展示了系统可扩展性差的问题，成功说服了相关人员。
• S 系统：通过整理线上故障数据和对比其他系统，清晰地展示了系统可用性的问题。
• C 系统：通过换位思考，找到了 C 系统在现有架构下的痛点，成功推动了 C 系统的合作。

12、架构重构 3：运筹帷幄

（1）架构重构的重要性

• 历史遗留问题：系统因历史原因和未及时处理的问题积累，导致各种问题集中爆发。
• 关键复杂度问题：架构师需要从众多问题中识别出关键的复杂度问题，并进行有针对性的重构。

（2）运筹帷幄的必要性

• 准备工作：在识别出关键复杂度问题后，需要识别并解决为了解决这些问题所需的准备工作。
• 分阶段实施：将问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标。

（3）分阶段实施的具体策略

• 优先级排序：
  • 解决明显且紧急的问题，如系统扩容。
  • 确保系统处于相对稳定的状态，减少频繁的线上问题。
• 问题分类：
  • 将问题按性质分类，每个阶段集中解决一类问题。
  • 例如，X 系统的第二阶段将多个底层系统切换到公司统一的公共组件，提升整体可用性。
• 先易后难：
  • 从简单的问题开始，逐步解决复杂的难题。
  • 每个阶段都有明确目标，效果明显，团队信心足。
  • 降低总体风险，避免一开始就做最难的部分导致项目停滞。
• 循序渐进：
  • 每个阶段最少 1 个月，最长不超过 3 个月。
  • 如果评估超过 3 个月，再拆分为更多阶段。

（4）实际案例

• X 系统：
  • 第一阶段：救火（扩容、Nginx 一键切换功能）。
  • 第二阶段：优化（解决明显的可用性问题）。
  • 第三阶段：服务化（重构核心架构）。
• S 系统：
  • 第一阶段：救火（扩容、Nginx 一键切换功能）。
  • 第二阶段：优化（解决可用性问题）。
  • 第三阶段：重构（单点数据库改为多中心）。

（5）长期重构项目的处理

• 重新评估：
  • 确认项目规模是否过大，是否可以先重构最核心最重要的部分。
  • 砍掉非关键功能，拆分成多个子重构项目。
• 分阶段规划：
  • 每个阶段最多半年，计划详细程度递减。
  • 一年后的计划不需要对外公布，每半年一个里程碑。
• 敏捷思维：
  • 采用敏捷开发的思想，排优先级，从高风险、高价值的需求开始，小步快跑，不断更新小版本。

13、开源项目的选择和二次开发

（1）选择开源项目

• 聚焦业务需求：选择开源项目时，首要关注是否满足业务需求，而非单纯追求项目的性能或功能。
• 选择成熟项目：尽量选择成熟、稳定的开源项目，避免使用尚在早期阶段的项目。
• 考察运维能力：
  • 版本号：选择版本号较高的项目。
  • 使用公司数量：选择被更多知名公司使用的项目。
  • 社区活跃度：检查社区的活跃度，如发帖数、回复数、问题处理速度等。

（2）使用开源项目

• 深入研究和测试：
  • 研究项目文档：通读设计文档或白皮书，了解设计原理。
  • 测试关键配置：核对每个配置项的作用和影响，识别关键配置项。
  • 性能和压力测试：进行多种场景的性能测试和压力测试。
• 小心应用，灰度发布：
  • 非核心业务先行：先在非核心业务上使用，逐步扩展。
  • 保持敬畏之心：线上环境复杂，即使测试再充分也要谨慎。
• 做好应急措施：
  • 备份方案：对于重要业务或数据，最好有另一个成熟方案做备份。
  • 故障恢复：确保有故障检测和恢复的能力。

（3）二次开发开源项目

• 保持原项目纯洁：
  • 开发辅助系统：开发监控、报警、负载均衡、管理等辅助系统，而不是直接修改原项目。
  • 提出需求或 bug：如果需要改动，可以向开源项目提需求或 bug，等待官方更新。
• 发明自己的轮子：
  • 成本和收益分析：根据业务需求和资源情况，决定是否自行开发。
  • 定制化开发：如果现有开源项目无法满足特定需求，可以投入资源进行定制化开发。

（4）云服务 vs. 自建

• 业务初期：
  • 使用云服务：运维方便，成本低，适合业务初期。
• 业务发展后：
  • 自建系统：根据业务特性进行定制开发，提高灵活性和性能。
• 综合考虑：
  • 运维成本：云服务减少了运维成本，但费用较高。
  • 个性化需求：自建系统更适合有个性化需求的业务。

（5）开源项目的学习

• 正确的学习观念
  • 避免"拿来主义"：仅仅使用开源项目而不深入了解其原理，会导致技术水平停滞不前。
  • 学习目标明确：学习开源项目不仅是为了更好地应用，更是为了提升自己的技术能力。
• 避免常见误区
  • 不要一开始就看源码：应该先了解功能、原理和关键设计。
  • 不要只关注数据结构和算法：虽然重要，但在学习开源项目时并不是最重要的。
  • 不要被项目规模吓倒：即使是大型项目，也可以逐步学习和理解。
• "自顶向下"的学习方法
  • 第一步：安装
    • 了解依赖：通过安装过程了解项目的依赖组件。
    • 获取基本信息：安装目录和文件结构提供使用和运行的基本信息。
  • 第二步：运行
    • 掌握命令行和配置文件：了解系统的能力和运行方式。
    • 实践操作：通过修改配置项观察系统的变化。
  • 第三步：原理研究
    • 系统性学习：深入理解项目的关键特性和实现原理。
    • 对比分析：通过对比类似系统，了解不同实现的优缺点。
    • 学习手段：
      • 通读项目的设计文档。
      • 阅读网上已有的分析文档。
      • 写 Demo 进行验证。
  • 第四步：测试
    • 实际测试：在实际项目中使用前进行测试，确保测试结果符合业务场景。
    • 测试时机：在原理研究之后进行测试，避免因不熟悉系统而导致错误结论。
  • 第五步：源码研究
    • 学习具体实现：理解原理背后的编码实现，提升自己的技术能力。
    • 有的放矢：带着明确目的研究源码，避免通读所有代码。
• 时间管理和学习策略
  • 集中精力：与其蜻蜓点水地学习多个项目，不如集中精力深入研究一个项目。
  • 灵活安排：根据时间和精力灵活安排学习步骤，特别是源码研究。
  • 持续学习：学习是一个长期的过程，定期回顾和总结，逐步积累知识。
• 推荐的开源项目
  • Netty：高性能的网络编程框架。
  • Redis：高性能的键值存储系统。
  • Spring：广泛使用的 Java 应用框架。

14、App 架构的演进

（1）App 架构的演进历程

• Web App（包壳架构）：
  • 优点：快速开发、低成本。
  • 缺点：用户体验较差。
  • 适用场景：早期尝试性业务、资源有限的初创公司。
• 原生 App：
  • 优点：优秀的用户体验、充分利用移动设备的特性。
  • 缺点：开发成本高、跨平台重复开发。
  • 适用场景：业务复杂度高、对用户体验要求高的应用。
• Hybrid App：
  • 优点：平衡用户体验和开发速度，部分功能可以通过 Web 实现。
  • 缺点：体验仍然不及原生 App。
  • 适用场景：业务快速发展、需要快速迭代的应用。
• 组件化 & 容器化：
  • 优点：提高开发效率、增强系统的可扩展性和可维护性。
  • 缺点：增加了架构的复杂度。
  • 适用场景：大型超级 App，业务模块众多、团队协作复杂的项目。
• 跨平台 App：
  • 优点：减少重复开发、降低人力成本。
  • 缺点：用户体验与原生 App 仍有差距。
  • 适用场景：需要在多个平台快速上线的应用。

（2）未来趋势

• 更好的用户体验：随着技术的发展，未来的 App 架构将更加注重用户体验的提升。
• 更快的开发速度：通过更高效的开发工具和框架，提高开发速度。
• 统一的平台化：可能逐渐出现统一的平台层，屏蔽不同操作系统的差异，提供一致的 API。
• 云原生：随着 5G 和云计算的发展，未来的 App 可能更加依赖云端，手机更像是一个终端设备。

（3）实践建议

• 选择合适的架构：根据业务需求和技术背景，选择最合适的架构方案。
• 持续演进：随着业务和技术的发展，不断优化和调整架构。
• 关注用户体验：始终将用户体验放在首位，不断优化和提升。

15、架构设计文档模板

（1）架构设计文档的重要性

• 目的：帮助在实际进行架构设计时更好地编写相关文档。
• 背景：由于信息安全原因和复杂系统的篇幅限制，专栏无法直接给出详细的文档案例，但提供一个模板仍然非常必要。

（2）备选方案模板

• 需求介绍：描述需求的背景、目标、范围等。
• 需求分析：
  • 5W：Who（需求利益干系人）、When（需求使用时间）、What（需求的产出）、Where（需求的应用场景）、Why（需求需要解决的问题）。
  • 1H：关键业务流程。
  • 8C：性能、成本、时间、可靠性、安全性、合规性、技术性、兼容性等约束和限制。

（3）复杂度分析

• 高可用：分析系统在各种情况下的可用性要求。
• 高性能：计算系统的性能指标，如TPS（每秒事务处理量）和QPS（每秒查询量）。
• 可扩展：分析系统的扩展性需求。

（4）备选方案

• 至少3个备选方案：每个方案描述关键实现，无须详细实现细节。
• 评估：360度环评，根据评估会议结果修改文档。

（5）架构设计模板

• 总体方案：描述方案的整体结构，包括架构图和模块职责。
• 架构总览：给出架构图及描述，关键设计点。
• 核心流程：详细描述核心业务流程。
• 详细设计：
  • 高可用设计：确保系统在各种故障情况下的可用性。
  • 高性能设计：优化系统性能。
  • 可扩展设计：考虑系统的扩展性。
  • 安全设计：权限控制、身份识别等。
  • 其他设计：开发语言、公司标准等。
• 部署方案：硬件要求、服务器部署方式、组网方式等。
• 架构演进规划：分阶段实施的计划。

（6）实际应用中的注意事项

• 文档维护：架构设计文档需要长期维护，而业务需求设计文档则因需求频繁变化而维护困难。
• 工具选择：画图工具随意，PPT、Visio等均可。
• 架构图：包括架构包含的实体、关联关系及关键流程图。