├── img ├── subject-1.jpeg ├── subject-2.jpeg ├── subject-5.jpeg ├── subject-7.jpeg ├── subject-10.jpeg ├── subject-11.jpeg └── subject-12.jpeg ├── README.md ├── rpc.md ├── subject-4.md ├── subject-19.md ├── subject-8.md ├── subject-22.md ├── subject-16.md ├── subject-21.md ├── subject-12.md ├── subject-6.md ├── subject-14.md ├── subject-20.md ├── subject-2.md ├── subject-5.md ├── subject-10.md ├── subject-7.md ├── subject-15.md ├── subject-9.md ├── subject-17.md ├── subject-1.md ├── subject-11.md ├── subject-13.md ├── subject-18.md ├── subject-3.md └── bookmark.md /img/subject-1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/neowei/base-architect/HEAD/img/subject-1.jpeg -------------------------------------------------------------------------------- /img/subject-2.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/neowei/base-architect/HEAD/img/subject-2.jpeg -------------------------------------------------------------------------------- /img/subject-5.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/neowei/base-architect/HEAD/img/subject-5.jpeg -------------------------------------------------------------------------------- /img/subject-7.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/neowei/base-architect/HEAD/img/subject-7.jpeg -------------------------------------------------------------------------------- /img/subject-10.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/neowei/base-architect/HEAD/img/subject-10.jpeg -------------------------------------------------------------------------------- /img/subject-11.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/neowei/base-architect/HEAD/img/subject-11.jpeg -------------------------------------------------------------------------------- /img/subject-12.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/neowei/base-architect/HEAD/img/subject-12.jpeg -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 三高场景的基础架构理论知识 跳跃门:目录 2 | 3 | 架构师打怪练级的葵花宝典 ^_^ 觉得写得好 记得给星星 4 | 5 | 会随着时间与流行技术 定期会更新/增加章节 6 | 7 | 如需转载请注明出处 谢谢 如有疑问或咨询可加wechat:neowei1210 @水钻王小六 8 | -------------------------------------------------------------------------------- /rpc.md: -------------------------------------------------------------------------------- 1 | rpc模式抓取全链路的业务监控 2 | 1.通过rpc模式调用 获取调用路径及参数值 执行成功失败信息 运行间隔基准的收录 3 | 2.通过生成/抓取request_id 获取调用链路 并传递request_id到调用的服务 由此依次传递 即可获得所有链路调用情况 4 | 3.通过对日志组件强化 通过唯一线程号与集合键值对或MDC方式 捕获调用运行时的所有日志 5 | 4.通过apm的trace_id获得组件链路情况 如数据库 消息中间件等 6 | 5.rpc调用信息的搜索关联 对特定业务的挂钩信息 如需通过订单号查找整条链路 -------------------------------------------------------------------------------- /subject-4.md: -------------------------------------------------------------------------------- 1 | ## 第四章节 配置中心 2 | 服务应用 数据库 第三方控件组件或系统优化等相关的配置文本 3 | 4 | ### 4.1 通过工具/脚本更改配置 5 | 应用服务可以通过定制小工具或者shell脚本等 通过正则规则通配符等根据各环境下的配置信息 在编译前或使用持续集成来替换配置文件 可以与部署联合使用 6 | 7 | ### 4.2 配置集中化管理 8 | 由于庞大的系统有各类的配置 并且在不同的环境 所以需要把这些配置文本集中化灵活管理起来 在服务治理中心可以把这些配置分类归纳的管理 9 | 场景例子: 10 | 1) 通过各维度来区分配置文件 维度可分为项目/业务 环境(dev/test/prod等) 版本号 11 | 2) 可与本地文件配置联合使用 减少在配置中心配置过多配置 12 | 3) 通过配置中心 聚合统一使用的配置 避免二次配置等 13 | 14 | 15 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-19.md: -------------------------------------------------------------------------------- 1 | ## 第十九章节 灾备 2 | 灾难备援 提前建立系统化的数据应急方式 以应对灾难的发生 3 | 4 | ### 19.1 副本方式 5 | 与原来的系统克隆一套一样的系统 一般都为异地机房 但硬件配备可能不如原来的系统 只做一个副本用来切换 6 | 场景: 7 | 1)主要系统无法短时间修复 8 | 2)机房停电或者不可抗力时 9 | 3)需要做全链路压测 10 | 11 | ### 19.2 多活 12 | 在副本方式之上 做到可以动态的直接切换整个服务 13 | 14 | ### 19.3 应用系统灾备 15 | 通常系统应用出现问题 非关键的可通过降级下线开关等方式避免一些问题 如遇灾难性问题 可通过副本方式切换 16 | 17 | ### 19.4 数据库灾备 18 | 定时或实时的做数据库备份 且通过同步机制来做异地备份 19 | 20 | 上一章节 下一章节 21 | -------------------------------------------------------------------------------- /subject-8.md: -------------------------------------------------------------------------------- 1 | ## 第八章节 分布式事务 2 | A应用服务调用B应用服务 有事务需求 则需要同时成功或同时回滚或中断调用的服务 3 | 4 | ### 8.1 分布式事务处理 5 | 多个应用间的事务调用 通常通过远程调用方式 有长连接方式直到两者都成功一起提交 6 | 短连接则分段提交如出错则通过回滚接口告知其回滚 两者方式都存在风险 第一种存在超时情况 第二种对开发测试要求过高 但可通过事务监控管理来改善风险 7 | 场景: 8 | 1) 跨银行操作交易记录 9 | 2) 积分或优惠券锁定 10 | 3) 对库存的操作 11 | 4) 调用第三方业务 12 | 13 | ### 8.2 事务监控管理 14 | 为了提高事务操作的性能及在高并发情况下 多个业务之间的事务调用 会分离事务 通过另外一个事务管理应用去管控多个应用之间的事务 监控整条链路的事务情况一旦出现问题可及时告知回滚取消 有监视的方式 也有告知响应的方式 15 | 16 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-22.md: -------------------------------------------------------------------------------- 1 | ## 第二十二章节 测试 2 | 测试分黑白灰测试 在服务治理层面 主要做黑盒测试中的压力测试与链路测试 3 | ### 22.1 压力测试 4 | 通常对单个API接口进行压力测试 从而找出此接口的性能点的瓶颈及qps的能力 针对其抗压能力 可进行动态扩容达到 5 | 场景: 6 | 1)使用开关来检测接口在调用与不调用内部其他接口情况的性能 7 | 2)在不使用缓存或使用的场景下的性能提升 8 | 3)数据库优化后 对应用程序的性能影响 9 | 10 | ### 22.2 全链路测试 11 | 链路测试 对入口层的接口进行测试 通常可以通过此次请求追踪到某个系统或应用对整体性能的影响及故障点 12 | 全链路测试就是通过模仿真实环境的用户或第三方调用 进行系统整体的测试 通常带有用户的随机性 这样可找出链路真实问题 13 | 场景: 14 | 1)电商系统 模拟多个用户购物/抢购 15 | 2)CRM系统 模拟满载电话接入 16 | 3)大数据 模拟计算实时离线数据 17 | 18 | 上一章节 -------------------------------------------------------------------------------- /subject-16.md: -------------------------------------------------------------------------------- 1 | ## 第十六章节 实例管理 2 | 从资产 容器 应用各项管理来达到应用实例的管理 3 | 4 | ### 16.1 资产管理 5 | 对硬件实体机或宿主机进行管理 创建主机 主机基础信息录入(cpu型号核数 内存大小 硬盘等等) 与容器存在依赖关系 6 | 7 | ### 16.2 容器管理 8 | 对容器进行管理 一键创建删除容器 配置容器各参数(cpu核数 内存等) 与应用服务存在依赖关系 可通过服务治理中心直接创建容器并匹配到具体应用 9 | 10 | ### 16.3 应用管理 11 | 分配容器给所需应用服务 包括各项优化参数等(jvm) 12 | 13 | ### 16.4 弹性扩容 14 | 通过实例管理 来弹性的扩容实例机器 横向上下架硬件主机 15 | 场景: 16 | 1)举办活动 流量突发上涨 17 | 2)需要一次性的离线计算 增强大数据的计算能力 18 | 3)迁移文件数据需要副本主机 19 | 20 | 21 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-21.md: -------------------------------------------------------------------------------- 1 | ## 第二十一章节 应急响应 2 | 在以无法通过服务治理中心操作解决的问题时 通知到应急响应部门 并尽可能的辅助应急响应部门解决问题 3 | 4 | ### 21.1 报警机制 5 | 当系统 应用服务 流量等出现异常时 会及时的向相关人员发送警报 6 | 场景: 7 | 1)应用服务宕机 8 | 2)网络故障 9 | 3)磁盘写满 10 | 4)cpu/内存/io持续过高 11 | 5)应用服务超时报警 12 | 6)自动熔断降级 13 | 14 | ### 21.2 流量实时监控 15 | 对各级流量进行实时大屏监控 一旦出现报警或问题 可第一时间采取措施 16 | 17 | ### 21.3 预警 18 | 根据各项参数如(时间 流量 负荷 出错率等) 做一些预警算法来预测是否有需要报警的情况出现 也可通过机器学习来达到预警效果 19 | 场景: 20 | 1)流量突发增大 疑似攻击 21 | 2)出错率无征兆增大 22 | 3)高峰期预算 硬件能力计算 23 | 24 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-12.md: -------------------------------------------------------------------------------- 1 | ## 第十二章节 计划任务 2 | 在系统中 经常会制定一些计划任务 在某个时间点做某件事情 核心是以时间为关注点 即在一个特定的时间点 系统执行指定的一个操作 3 | 4 | 5 | ### 12.1 任务调度 6 | 任务调度涉及多线程并发 线程池维护 运行时间规则解析 任务链路追踪 运行时长基准 日志收集 运行保护 重试恢复等 7 | 场景例子: 8 | 1) 定时发送活动短信/邮件 9 | 2) 大数据相关 如离线计算用户喜好 10 | 3) 脏数据冗余数据清理 11 | 4) 定时同步数据库和缓存 12 | 5) 13 | 14 | ### 12.2 调度管理 15 | 在服务治理中心管控这些任务 16 | 基本功能创建任务(根据设置调用的版本 会自动找相应的服务) 发起任务 调用任务接口 任务的运行时长跟状况 运行错误报警 任务运行日志的收集查看 重新发起任务等等一系列的管控任务的功能 17 | 18 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-6.md: -------------------------------------------------------------------------------- 1 | ## 第六章节 应用接口字典 2 | 应用服务的出入口 基于各网络协议形式的调用 3 | 如tcp restful webservice thirft等 用于应用服务间调用或客户端等调用 4 | 5 | ### 6.1 接口API上报 6 | 接口的名称 描述 请求地址 请求参数 返回结果模型 上报至服务治理中心/接口管理中心 对接口进行管理 且根据业务/版本进行归纳划分 7 | 8 | ### 6.2 接口API字典 9 | 通过接口信息进行接口查询 10 | 场景例子: 11 | 1) 开发阶段 对其他业务线的接口查询 减少沟通成本 12 | 2) 基础接口/常用接口的查询使用 避免重复造轮开发 13 | 3) 通过工具脚本做自动化生成工具或脚手架功能等 14 | 15 | ### 6.3 接口API(自动化)测试 16 | 通过接口信息描述等 可对接口进行测试 并对返回数据(返回结果集是json的情况)通过json schema进行检测 也可通过工具脚本形成自动化测试 17 | 18 | 19 | 20 | 21 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-14.md: -------------------------------------------------------------------------------- 1 | ## 第十四章节 负载均衡 2 | 应用服务集群化 通过负载均衡的规则跟算法 把请求平均分布到应用集群的每台机器上 从而达到资源平均分配 有效的抵抗高并发 3 | 4 | ### 14.1 负载均衡规则算法 5 | 常用负载均衡规则算法有(加权)轮询法 (加权)随机法 最小连接数法 计数法 6 | 根据硬件场景等实际情况选取不同的规则算法 7 | 场景: 8 | 1)硬件性能不同 则把负载更多的放到好的硬件机上 9 | 2)不同的版本 更多的把负载放到稳定的版本的机器上 10 | 3)系统的负载 把负载更多的均配到负载低的机器上 11 | 12 | ### 14.2 流量控制 13 | 有些场景需要对流量到系统或应用进行控制 14 | 流量控制可集成在服务治理中心进行配置及管理 15 | 场景: 16 | 1)应用上线后 不加入负载均衡策略 可定制优先放量百分比或实际数字到此应用 观察其情况 是否达到上线标准 17 | 2)机器异常或出现未知故障 对其可进行流量管控 便于查询此机器的实际问题 18 | 3)链路压测时 对单机性能的消耗评估等 19 | 20 | 21 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-20.md: -------------------------------------------------------------------------------- 1 | ## 第二十章节 安全 2 | 安全版块细分会有很多 针对服务治理主要有两块 3 | 4 | ### 20.1 黑白名单 5 | 对外网访问会设置黑白名单的权限 路由网关层会有黑白名单的缓存 或者有单独一个应用来做黑白名单服务 6 | 场景: 7 | 1)乙方公司访问 乙方公司ip白名单 8 | 2)黑客或者对手公司进行攻击 对其或肉机ip进行封杀 9 | 3)政治问题导致有些国家不能访问的ip段封锁 10 | 11 | ### 20.2 漏洞扫描 12 | 通常可针对API接口及容器自身 进行漏洞扫 在服务治理层面 只做针对API接口的漏洞检测扫描 13 | 场景: 14 | 1)应用第三方依赖包中早期版本中有漏洞 比如最近的fastjson漏洞 15 | 2)应用自身容器存在漏洞 如ioc容器spring web容器tomcat 16 | 3)对外接口层面的异常暴露 信息泄露 状态码合规 伪造跨域请求 伪造身份认证等 17 | 18 | ### 20.3 风险控制 19 | 通过风控规则引擎 模型引擎等 对一些作弊或者非法方式的访问进行规避或收集 20 | 场景: 21 | 1)修改购买实际价格 红包 积分等 22 | 2)电商系统商家刷单 以谋取好评 销量 23 | 24 | 25 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-2.md: -------------------------------------------------------------------------------- 1 | ## 第二章节 分布式锁 2 | 由于应用集群多节点化 则会导致重复提交在不同节点 多节点操作同一数据 操作顺序不一致等 所以需要分布式锁来控制节点 3 | 4 | ### 2.1 基于缓存/数据库的分布式锁 5 | 基于缓存的锁 如redis 或者关系型数据库的锁或事务机制来达到分布式锁 6 | 场景例子: 7 | 1) 抢购活动计数 8 | 2) 积分/金额操作 9 | 3) 库存操作 超卖问题 10 | 11 | ### 2.2 第三方分布式锁 12 | 基于zookeeper/doozer/etcd等专用于做分布式锁的工具第三方组件 13 | 场景例子: 14 | 1) 多次点击 防止重复提交 导致数据冗余或出错 15 | 2) 安全相关 可通过此无限提交导致服务出问题 16 | 17 | ### 2.3 基于文件的分布式锁 18 | 在多应用多系统场景下 文件操作的锁 告知操作系统/系统命令或使用分布式锁工具 来锁定此文件 19 | 场景例子: 20 | 1) 多个应用同时写入文件 21 | 2) 文件被幻读或无此文件 22 | 23 | ### 2.4 防重复提交机制 24 | 在多应用情况下 为避免相同操作程序重复执行 可通过web服务器规避重复提交至应用 或使用分布式session机制 或者分布式锁机制等来避免 25 | 26 | 上一章节 下一章节 27 | -------------------------------------------------------------------------------- /subject-5.md: -------------------------------------------------------------------------------- 1 | ## 第五章节 应用版本 2 | 应用的版本管理 需上报到服务治理中心 3 | 4 | 5 | ### 5.1 多版本共存 6 | 应用服务集群中会存在多个版本 7 | 场景例子: 8 | 1) 多节点灰度部署 9 | 2) 上线出现问题执行回滚 10 | 3) 客户端/其他业务调用不同版本的服务端 版本差异化 11 | 12 | ### 5.2 版本差异使用 13 | 非强制要求其他服务或客户端升级时 就存在多个版本差异化的使用 14 | 通过服务治理中心得知具体版本的节点则调用使用 15 | 场景例子: 16 | 1) 客户端/内部系统多个版本 不同版本调用不同的应用服务 17 | 2) 内部系统调用未及时升级会对上一次版本或之前的版本有依赖 18 | 3) 用户使用端未更新调用历史版本的接口 19 | 20 | ### 5.3 版本管理 21 | 通过服务治理中心 提前通知告知与其有调用关联的其他服务 22 | 如下个版本不在提供那些版本的服务 让其及时升级新的使用版本服务 23 | 场景例子: 24 | 1) 依赖业务/客户端调用新老版本时 提示警告或转发 25 | 2) 通过路由来过滤 指定到某个特定版本 26 | 3) 接口字典查询 用版本来定位所需查询的接口 27 | 28 | 29 | 30 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-10.md: -------------------------------------------------------------------------------- 1 | ## 第十章节 路由与网关 2 | 由于应用服务存在多个 无法归纳统一对外访问地址 造成对外接口特别复杂 3 | 所以针对于业务层面 需要一个入口层 一般我们称其为路由层 4 | 5 | 6 | 7 | ### 10.1 动态路由 8 | 路由层为入口层 一般会为其设置host(域名) 达到统一访问地址 通过请求的解析 找到所需要的服务群 执行请求并转发或者代理到需要的服务 返回请求所需的结果 9 | 动态路由的含义则是在无需对路由层更改的情况下 路由可通过网关或服务治理中心得知到新的服务 10 | 场景例子: 11 | 1) 通过对外统一域名 通过外部请求解析到具体的内部服务路由 12 | 2) 开放式平台 OAUTH安全验证 统一内部接口 13 | 3) 对外webservice接口(如银行证券等) soap验证 统一内部接口 14 | 4) 需要加密场景 对客户端与服务端的对称加密 15 | 16 | ### 10.2 网关模式 17 | 路由可包含网关层 也可抽离 网关主要能快速定位到所需访问的服务 同时网关层有负载均衡及放量控量等功能 18 | 场景例子: 19 | 1) 多节点的负载均衡 20 | 2) 灰度上线 控制放量到灰度的实例 21 | 3) websocket负载(如用golang) 业务分离(业务由其他语言执行) 22 | 23 | 上一章节 下一章节 24 | 25 | -------------------------------------------------------------------------------- /subject-7.md: -------------------------------------------------------------------------------- 1 | ## 第七章节 应用调用接口 2 | 应用之间的如何调用接口 通常分为远程调用与内部调用 还有以消息中间件形式异步调用 3 | 4 | 5 | ### 7.1 远程调用 6 | 远程调用 两个独立应用(集群)间的调用 常用协议tcp restful webservice thirft等 7 | 场景: 8 | 1) 订单模块调用商品/支付/物流模块 9 | 2) 路由模式 客户端对路由层发送请求 路由层对内部服务发送请求 10 | 3) 任务调度 调用业务接口的定时任务 11 | 12 | ### 7.2 内部调用 13 | 内部本地方法调用 进程内调用 如java以jar包形式反射调用 命令调用系统底层 14 | 场景: 15 | 1) A应用集群宕机 B需要调A切换至内部反射用A的引入的jar包 16 | 2) 图形服务 原本使用第三方系统处理 第三方系统出错 则使用自己本地的图形处理方式 17 | 18 | ### 7.3 消息中间件调用 19 | 应用服务发送至消息中间件直接返回 其他应用再去把消息中间件上的消息处理 非即时处理 具体可参见 第十一章节 事件总线与消息队列 20 | 场景: 21 | 1) 订单完成 因其订单无需即时物流反馈 则可通过消息中间件异步发送到物流平台 22 | 2) 12306抢票 抢票发送至消息中间件 再由订票系统去处理 处理完后得知是否抢票成功 23 | 3) 应用产出日志 发送至消息中间件 日志系统可缓冲收集清洗日志 24 | 25 | 26 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-15.md: -------------------------------------------------------------------------------- 1 | ## 第十五章节 容错机制 2 | 当应用或系统出现问题时 应自动智能的实行一些容错熔断机制来保证系统应用的高可用和健壮性 3 | 4 | ### 15.1 自动熔断 5 | 在一些特定的情况下 应自动熔断系统或应用 6 | 场景: 7 | 1)容器io cpu 内存等参数负荷异常过高 8 | 2)当应用出错率达到设置的百分比 9 | 3)日志监控到应用日志重复异常过多 10 | 4)应用写入的硬盘已满 11 | 12 | ### 15.2 超时容错 13 | 在系统中超时是很常见的问题 但当超时过多 影响了整体应用以及业务时 应自动将此应用做一些容错操作 14 | 场景: 15 | 1)超时时间设置过短 自动提升超时时间在可允许范围内 16 | 2)活动期间 超时飙升 系统自动把一些非必要的服务下线或降级 17 | 3)双11抢购 天猫下单即时改为下单准即时(利用消息队列) 18 | 4)微信支付服务超时严重 自动关闭支付入口或隐藏 19 | 20 | ### 15.3 应用心跳检测 21 | 应用服务的存在进行主动的心跳检测 观察其是否可用 22 | 场景: 23 | 1)服务宕机 24 | 2)网络问题 25 | 3)服务更新 26 | 27 | ### 15.4 降级下线 28 | 可通过状态码开关等功能 实现服务降级 整体应用服务或系统下线 29 | 场景: 30 | 1)银行服务无法调用 导致无法支付 支付模块降级 31 | 2)升级导致服务无法使用 让整体服务应用降级 32 | 3)第三方组件中间件数据库出现故障 导致整体服务无法使用 33 | 34 | 35 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-9.md: -------------------------------------------------------------------------------- 1 | ## 第九章节 编译部署 2 | 应用服务在各环境进行编译部署 3 | 4 | ### 9.1 一键部署 5 | 通过预先设置好的参数跟脚本或工具以及配置 达到点击一次按钮 编译业务应用代码 执行单元测试 并把编译后文件部署到所对应的容器 从而达到持续部署与滚动更新 6 | 场景例子: 7 | 1) 通过tag号 直接拉取代码 根据生成出的配置文件 进行编译 并把编译后文件上传至容器上并启动 8 | 2) 灰度场景下 通过按钮 一键下线不参与负载 并通过按钮一键上线 并放量快速测试节点 9 | 3) 滚动更新 滚动进度查询 滚动历史记录 回滚历史版本 10 | 11 | ### 9.2 热部署 12 | 通过不重启应用服务 达到新的功能代码能够动态的部署到应用服务 13 | 场景例子: 14 | 1) 更新配置文件/配置中心配置更改 15 | 2) 重新加载/刷新本地缓存 16 | 3) 加载动态编译的代码/模块 17 | 18 | ### 9.3 灰度部署 19 | 保证应用的可用性 再不停止服务的情况下能继续使用服务且能进行更新 通过应用节点 下线其中一台机器不参与负载(可不下) 关闭流量 关闭服务 尝试对此节点进行上线 通过控量放量 来观察新版本在真实环境中是否有错误及性能问题的情况 然后进行ABTest 放量进行测试 成功后切换资源并释放闲置资源 20 | 场景例子: 21 | 1) 伪上线/沙箱环境与上线环境切换 22 | 2) 不下线老版本资源 只上线新的版本 如无问题 再释放老版本的资源 23 | 3) 通过路由层来路由到具体的版本或新上线的应用 24 | 25 | ### 9.4 多版本差异节点部署 26 | 参照第五章 应用版本 27 | 28 | 29 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-17.md: -------------------------------------------------------------------------------- 1 | ## 第十七章节 监控 2 | 系统监视以及网络监视功能的企业级的开源解决方案 监视各类参数 保证系统应用的安全运营 3 | 提供灵活的通知机制以让运维等相关人员快速定位解决存在的各种问题 4 | 5 | ### 17.1 容器监控 6 | 对容器的基础信息监控(cpu/内存/各io/磁盘容量) 包括宿主机的监控 7 | 场景: 8 | 1) cpu 长时间使用率100% 9 | 2) 网络io突发占满 10 | 3) 磁盘写满或无法读取写入 11 | 12 | ### 17.2 应用监控 13 | 对应用活动状态的监控 一般有正常 警告 下线 出错等状态 还有对应用处理请求流量的监控 如pv uv ip qps 14 | 场景: 15 | 1) 服务升级 下线状态 16 | 2) 服务出现呈现高负荷流量过高 警告状态 17 | 3) 服务出现大量异常错误超时 出错状态 18 | 4) apm 应用性能监控 vm级监控 请求trace采集 19 | 20 | ### 17.3 业务监控 21 | 对业务的执行时间进行监控 通常有通过接口 方法 自建业务埋点 探针方式 22 | 场景: 23 | 1) 链路测试 问题排查 24 | 2) 特定代码块有需要观察是否有超时情况 25 | 3) 超时时间设置限定 26 | 4) 代码业务优化 27 | 28 | ### 17.4 中间件组件数据库监控 29 | 对数据库的负载 硬盘数据 网络传输情况以及各操作的执行时间监控 30 | 对中间件 如MQ的负载 消息堆积情况进行监控 31 | 对缓存redis的负载 内存情况 32 | 场景: 33 | 1) redis内存用尽 连接数过高 34 | 2) 数据库超时严重 连接数耗尽 磁盘写满等 35 | 3) mq消息堆积严重 36 | 37 | 38 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-1.md: -------------------------------------------------------------------------------- 1 | ## 第一章节 服务治理中心 2 | 服务治理的管理平台 3 | 4 | ### 1.1 应用服务的注册 5 | 应用服务自身基本信息的上报 一般跟随启动时注册 应用服务区别化 6 | 场景例子: 7 | 1) 告知收集应用服务器/应用容器信息(如:应用服务名,应用服务描述,应用服务ip/域名,各版本信息等) 8 | 2) 治理中心进行上次比对是否有更新 版本的变化 对于无状态的k8s容器则以 9 | 填充方式 10 | 11 | ### 1.2 治理中心发现应用服务 12 | 服务治理中心可针对容器进行监控或心跳机制监测应用服务 13 | 可动态发现服务是否存在上线下线或部署等状态 14 | 场景例子: 15 | 1) 通过心跳机制或监控方式探知应用服务的情况及状态 16 | 2) 针对各种情况状态做出相应操作 如异常或宕机使其下线或降级 17 | 18 | 19 | ### 1.3 应用服务通知治理中心 20 | 当应用服务发生变化或者下线降级操作时 通知治理中心其现在状态 21 | 场景例子: 22 | 当应用服务自身发生变化时 如下线配置变化 磁盘写满 无法连接数据库中间件等 则先通知服务治理中心 让服务治理中心做出相应操作 23 | 24 | ### 1.4 治理中心广播应用服务 25 | 当应用服务发生变化 广播至与其有关联的应用服务 26 | 场景例子: 27 | 1) 治理中心得知应用服务有所变化 如需广播的情况下 则广播至有关联的应用服务 28 | 2) 如订单服务升级 则应通知商品物流支付或其他相关业务正在部署升级或灰度下线了那些容器 29 | 30 | ### 1.5 治理中心权限管理 31 | 治理中心管理平台自身管理员的权限管理以及应用服务的权限管理 32 | 场景例子: 33 | 1) 如财务版块应用不是所有应用可以访问 则需要设置权限 34 | 2) 管理员需分角色 开发 架构师 运维等所呈现界面则应不同 35 | 36 | 下一章节 -------------------------------------------------------------------------------- /subject-11.md: -------------------------------------------------------------------------------- 1 | ## 第十一章节 事件总线与消息队列 2 | 事件总线是一个概念 消息队列是事件总线的一种实现 通过消息队列来达到业务分离 也可使业务串行并行化 3 | 4 | 5 | ### 11.1 事件总线 6 | 事件总线是一种概念 通常有发布订阅模型 乒乓模型 Actor模型等 常用实现框架有Disruptor JActor EventBus等 7 | 常用的发布订阅模式是事件总线的一种实现 它是一种集中式事件处理机制 允许不同的组件之间进行彼此通信而又不需要相互依赖 达到一种解耦的目的 8 | 场景例子: 9 | 1) amqp消息队列 10 | 2) 网络proactor/reactor模型 11 | 3) request response模式(java的servlet模式) 12 | 4) 异步协程模型 callback/promise/async模式等 13 | 5) 通过异步模型引申出的rx/stream模型 14 | 15 | ### 11.2 消息队列 16 | 消息队列是一种通信工具 可以在机器之间互相传输消息文件等 扮演着一种消息路由的角色 拥有一套完备的路由机制来决定消息传输方向 发送段只需要向消息总线发出消息而不用管消息被如何转发 17 | 消息队列中间件是分布式系统中重要的组件 主要解决应用耦合 异步消息 流量削锋 18 | 消息队列的实现的中间件常用的amqp协议的有activemq/rabbitmq等 非amqp有kafka/redis等 19 | 场景: 20 | 1) 用户注册完成后需认证 可以对消息中间件发送请求 短信邮件服务消费 进行发短信发邮件并行处理 21 | 2) 流量削锋 12306订票 22 | 3) 应用解耦 电商系统(库存服务 订单服务 会员服务 物流服务) 23 | 4) 异步执行模型 离线任务等 24 | 5) 任务堆积 任务调度 定时执行 25 | 26 | 27 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-13.md: -------------------------------------------------------------------------------- 1 | ## 第十三章节 统一状态码 2 | 应用服务及系统返回需统一状态码 3 | 可分为通用状态码以及应用级的自设的状态码 通过服务治理中心统一管理所有应用及通用状态码 并可把状态码错误等级化 可通过抢注状态码 4 | 5 | ### 13.1 系统/通用状态码 6 | 系统标准的状态码 通用成功 错误或异常可以使用此状态码 7 | 场景例子: 8 | 1) 常用状态码 9 | 2) 降级状态码 10 | 3) 未知异常码 11 | 4) 未发现服务状态码 12 | 5) 超时状态码 13 | 6) 找不到文件页面状态码 14 | 15 | ### 13.2 应用/业务状态码 16 | 根据应用业务 自设应用状态码 17 | 场景例子: 18 | 1) 物流无法配送状态码 19 | 2) 订单失效状态码 20 | 3) 商品已下架状态码 21 | 4) 手机号错误状态码 22 | 5) 表单验证错误状态码 23 | 24 | ### 13.3 对内/对外状态码 25 | 对内部使用的状态码 并不适合给外部用户查看由此引发一些安全隐患 所以在路由层可能会转换内部状态码为外部使用状态码 26 | 场景例子: 27 | 1) 成功状态码 对外返回100 内部可能101使用缓存返回 102使用消息中间件 28 | 2) 业务状态码 对外返回400 账号无法使用请联系客服 内部401 账号在黑名单 402 账号异常登录 29 | 3) 异常状态码 对外返回500 服务维护/访问出错 对内 501 数据库连接异常 502数据库无法连接 30 | 31 | ### 13.4 状态码统计及监控 32 | 状态码统计跟监控 当出现错误级别的达到 可判定应用是否出现问题 并进行报警操作 33 | 场景例子: 34 | 1) 持续出现超时状态码 即可熔断其应用 35 | 2) 持续出现试探性撞库性的状态码 比如密码错误 可将其ip列入黑名单 36 | 3) 统计各项数据 呈现应用各指标 出现异常情况如何从而提现应用的健壮性 37 | 38 | 上一章节 下一章节 -------------------------------------------------------------------------------- /subject-18.md: -------------------------------------------------------------------------------- 1 | ## 第十八章节 应用日志 2 | 一套完善的系统是必须要有日志来支撑其健壮度的 开发测试阶段时 能直接反映出现的问题故障的排查 能及时的调节问题的故障 3 | 发生任何问题时 日志在第一时间可以反映出其问题的描述 可让运维开发排查问题定位问题所在 4 | 5 | ### 1.1 日志等级 6 | 在java日志中 一般分为trace上一章节 下一章节 -------------------------------------------------------------------------------- /subject-3.md: -------------------------------------------------------------------------------- 1 | ## 第三章节 开关 2 | 集中化管理各类开关 3 | 4 | 5 | ### 3.1 动态开关 6 | 通过键名获取变量 让其第一时间告知应用群或各个业务系统 并通过分布式锁(第二章)方式加锁避免冲突 7 | 通过服务治理中心广播或插件形式主动访问形式 可定制开关缓存时间减少对中心的访问 8 | 开关可大大的提升可用性 也可在一定程度可减少开发需求 9 | 10 | ### 3.2 系统开关 11 | 用于系统级别的开关 此开关通常用于解决系统一些故障问题灾难或突发性高频访问等等 12 | 场景例子: 13 | 1) 打开/关闭所有日志输出或输出到elk 14 | 2) 打开/关闭使用外部缓存或中间件 15 | 3) 切换机房/网络(类似多活) 16 | 4) 子系统故障切换模式或直接降级 17 | 5) 灾难问题 可以将非关键的整体系统下线或降级开关 18 | 6) 单/双写数据库切换或是否写入大数据 19 | 7) 全局需变更的配置/参数 20 | 21 | ### 3.3 应用开关 22 | 用于应用基础框架或第三方组件的内置开关 23 | 针对单个应用或应用集群的开关模式 24 | 场景例子: 25 | 1) 设置应用的日志等级/过滤 日志的根据等级动态输出 26 | 2) 应用客户端访问数据库连接池线程池大小的切换 27 | 3) 针对当前应用是否使用风控/黑白名单检测 28 | 4) 远程调用/内部调用切换开关 29 | 5) 切换远程调用的协议 30 | 6) 生产测试开发切换开关 31 | 7) 应用是否使用本地或外部缓存 32 | 8) 百分比 阈值的变更 33 | 9) 磁盘写满 清理磁盘文件缓存或删除无用文件操作 34 | 35 | ### 3.4 业务开关 36 | 通过开关的改变对业务的一些需要变更的情况 能够实时的一键切换 同时也解决了一些一次性需求 减少开发任务 以及一些代码逻辑块算法块上的控制走那条策略 37 | 场景例子: 38 | 1) 设置库存最大上限/每人每日限购等一些需要动态改变的参数 39 | 2) 关闭/更改抢购/限时活动接口 40 | 3) 设置打折力度 优惠券获得或使用方式 41 | 4) 支付/物流方式更换 比如支付宝微信银联关闭或开放 42 | 5) 商品推荐 走推荐引擎或随机推荐等 43 | 6) 推荐引擎使用什么算法计算 离线计算使用什么算法 44 | 45 | 46 | ### 3.5 降级开关 47 | 当某个子系统或应用出现问题时 通过开关或降级操作能保证整个大系统可继续使用 48 | 场景例子: 49 | 1) 风控系统出现问题 不影响业务 通过开关设置返回成功状态码 使得其他系统正常运行 50 | 2) 使用中间件/数据库持久化数据的传递 等其系统修复后 恢复中间件上的数据 51 | 52 | 53 | 上一章节 下一章节 -------------------------------------------------------------------------------- /bookmark.md: -------------------------------------------------------------------------------- 1 | title: 高可用安全架构解决方案 2 | speaker: Neo Wang 3 | transition: slide3 4 | theme: moon 5 | usemathjax: yes 6 | 7 | [slide] 8 | ## 高可用安全基础架构解决方案 9 | ### 作者: 王玮 10 | 11 | [slide] 12 | ## 第一章节 服务治理中心 13 | * 1.1 应用服务的注册 14 | * 1.2 治理中心发现应用服务 15 | * 1.3 应用服务通知治理中心 16 | * 1.4 治理中心广播应用服务 17 | * 1.5 治理中心权限管理 18 | 19 | [slide] 20 | ## 第二章节 分布式锁 21 | * 2.1 基于缓存/数据库的分布式锁 22 | * 2.2 第三方开发的分布式锁 23 | * 2.3 基于文件的分布式锁 24 | * 2.4 防重复提交机制 25 | 26 | [slide] 27 | ## 第三章节 开关 28 | * 3.1 动态开关 29 | * 3.2 系统开关 30 | * 3.3 应用开关 31 | * 3.4 业务开关 32 | * 3.5 降级开关 33 | 34 | [slide] 35 | ## 第四章节 配置中心 36 | * 4.1 通过工具/脚本更改配置 37 | * 4.2 配置集中化管理 38 | 39 | [slide] 40 | ## 第五章节 应用版本 41 | * 5.1 多版本共存 42 | * 5.2 版本差异使用 43 | * 5.3 版本管理 44 | 45 | [slide] 46 | ## 第六章节 应用接口字典 47 | * 5.1 接口API上报 48 | * 5.2 接口API字典 49 | * 5.3 接口API(自动化)测试 50 | 51 | [slide] 52 | ## 第七章节 应用调用接口 53 | * 7.1 远程调用 54 | * 7.2 内部调用 55 | * 7.3 消息中间件调用 56 | 57 | 58 | [slide] 59 | ## 第八章节 分布式事务 60 | * 8.1 分布式事务处理 61 | * 8.2 事务监控管理 62 | 63 | [slide] 64 | ## 第九章节 编译部署 65 | * 9.1 一键部署 66 | * 9.2 热部署 67 | * 9.3 灰度部署 68 | * 9.4 多版本差异节点部署 69 | 70 | [slide] 71 | ## 第十章节 路由与网关 72 | * 10.1 动态路由 73 | * 10.2 网关模式 74 | 75 | [slide] 76 | ## 第十一章节 事件总线与消息队列 77 | * 11.1 事件总线 78 | * 11.2 消息队列 79 | 80 | [slide] 81 | ## 第十二章节 计划任务 82 | * 12.1 任务调度 83 | * 12.2 调度管理 84 | 85 | [slide] 86 | ## 第十三章节 统一状态码 87 | * 13.1 系统/通用状态码 88 | * 13.2 应用/业务状态码 89 | * 13.3 对内/对外状态码 90 | * 13.4 状态码统计及监控 91 | 92 | [slide] 93 | ## 第十四章节 负载均衡 94 | * 14.1 负载均衡规则算法 95 | * 14.2 流量控制 96 | 97 | [slide] 98 | ## 第十五章节 容错机制 99 | * 15.1 自动熔断 100 | * 15.2 超时容错 101 | * 15.3 应用心跳检测 102 | * 15.4 降级下线 103 | 104 | [slide] 105 | ## 第十六章节 实例管理 106 | * 16.1 资产管理 107 | * 16.2 容器管理 108 | * 16.3 应用管理 109 | * 16.4 弹性扩容 110 | 111 | [slide] 112 | ## 第十七章节 监控 113 | * 17.1 容器监控 114 | * 17.2 应用监控 115 | * 17.3 业务监控 116 | * 17.4 中间件组件数据库监控 117 | 118 | [slide] 119 | ## 第十八章节 应用日志 120 | * 18.1 日志等级 121 | * 18.2 集中化日志收集平台 122 | * 18.3 日志工具 123 | 124 | [slide] 125 | ## 第十九章节 灾备 126 | * 19.1 副本方式 127 | * 19.2 多活 128 | * 19.3 应用系统灾备 129 | * 19.4 数据库灾备 130 | 131 | [slide] 132 | ## 第二十章节 安全 133 | * 20.1 黑白名单 134 | * 20.2 漏洞扫描 135 | * 20.3 风险控制 136 | 137 | [slide] 138 | ## 第二十一章节 应急响应 139 | * 21.1 报警机制 140 | * 21.2 流量实时监控 141 | * 21.3 预警 142 | 143 | [slide] 144 | ## 第二十二章节 测试 145 | * 22.1 性能测试 146 | * 22.2 压力测试 147 | * 22.3 单元测试/覆盖率 148 | * 22.4 黑白灰测试 149 | * 22.5 全链路测试 150 | 151 | 152 | 153 | 154 | 155 | --------------------------------------------------------------------------------