目录
- 接口级别故障
接口级别故障
降级：丢车保帅
- 系统后门降级：系统提供一个降级URL
- 独立降级系统
熔断
- 阈值的设定
- 统一的API调用层
限流
- 基于请求限流
- 基于资源限流
排队
- 排队模块
- 调度模块
可扩展模式：“拆”
拆分思路
- 面向流程拆分 （如：展示层->业务层->数据层->存储层）分层架构
- 面向服务拆分 （注册服务->登录服务->信息管理服务->安全设置服务）SOA、微服务架构
- 面向功能拆分 （身份注册->系统登录->密码找回）微内核架构
不同的拆分方式，本质上决定了系统的扩展方式。
- 上述拆分方法可以组合使用，绝非非此即彼。
真正有生命力的软件系统都是在不断迭代和发展的。
分层架构
- C/S架构、B/S架构（划分维度：用户交互）
- MVC架构、MVP架构（划分维度：职责）
- 逻辑分层架构（自顶向下依赖的，划分维度：职责）如：操作系统内核、TCP/IP架构等。
本质在于隔离关注点（separation of concerns）.
通过分层强制约束两两依赖的，但代价是某一个操作在每一层中都要有实现。多少有性能缺失。
SOA(Service Oriented Architecture)
服务
ESB（Enterprise Service Bus）相同标准接口由协议联通
- 多种协议：JMS、WS、HTTP、RPC等
- 多种数据格式：XML、JSON、二进制、HTML等
- ESB组合各种异构系统（背景：新老系统共用）
- ESB可能会臃肿到成为整体系统的瓶颈
松耦合
微服务与SOA的区别
- 微服务是SOA的实现方式。微服务就是使用HTTP RESTful协议来实现ESB的SOA，使用SOA来构建单个系统就是微服务。微服务就是更细粒度的SOA。
- 微服务是去掉ESB的微服务，改为轻量级的HTTP实现。
- 微服务是一种和SOA相似但本质上不同的架构理念。
微服务与SOA的对比
- 服务粒度：SOA粗，微服务细。
- 服务通信：SOA采用ESB作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful协议、RPC协议，无须ESB这样的重量级实现。
Smart endpoints and dumb pipes.
dumb pipes体现在仅仅做消息传递，对消息格式和内容一无所知。
- 服务交付：采用自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。如果没有这些能力的支撑，微服务一旦变大（超过20个微服务），整体就难以达到快速交付的要求。
实行微服务有一个明显的坑：拆分系统为微服务后，部署的成本呈指数上升。 - 应用场景：SOA更加适合于庞大、复杂、异构的企业级系统，这也是SOA诞生的背景。这类系统的典型特征是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的，有的是外部购买的，无法完全推倒重来或进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是ESB。
微服务的缺陷：
- 服务划分过细，服务间关系复杂。
- 服务数量太多，团队效率急剧下降。
- 调用链太长（HTTP或RPC），性能下降。问题定位困难。
- 没有自动化支撑，无法快速交付。
- 没有服务治理，微服务数量多了后管理混乱。
微服务拆分过细，过分强调small。微服务基础设施不健全，忽略了automated。微服务并不轻量级，规模大了后，lightweight不再适应。
微服务最佳实践
两个披萨理论：每个团队的人数不能多到两个披萨都不够吃的情况。
- 可以3人一组。开发阶段的3个火枪手。
拆分方法
- 基于业务逻辑拆分：服务数量范围与职责范围
- 基于可扩展拆分：变与不变
- 基于可靠性拆分：核心与非核心
- 基于性能拆分：性能瓶颈
基础设施 automated
- 服务发现（自理式、代理式）、服务路由（路由算法：随机路由、轮询路由、最小压力路由、最小连接数路由等）、服务容错（微服务有故障扩散的缺点。容错种类：重试、流控、服务隔离）、服务监控、服务跟踪（标注点、跟踪树和span。目的：采样跟踪和染色跟踪）、服务安全（接入安全、数据安全、传输安全）
- 自动化测试、自动化部署、配置中心、接口框架（指定协议、数据规范）、API网关
- 上述功能其实都是从ESB的功能中剥离出来的。
微内核架构 MicroKernel Architecture 插件化架构 Plug-in Architecture
- 核心系统（core system）负责与具体业务无关的通用功能，如：模块加载、模块间通信
- 插件模块（plug-in modules）负责具体的业务逻辑，如：学生管理系统的手机号注册功能
插件模块可以根据业务功能的需要不断地扩展，微内核架构通过隔离变化到插件的方式提供了灵活性、可扩展性。
微内核
- 插件管理（核心系统提供插件注册表）
- 插件连接（Eclipse使用的OSGI、消息模式、Spring使用的依赖注入、分布式协议（RPC或者HTTP Web））
- 插件通信（核心系统提供）
OSGI架构简析
- 模块层
- 生命周期层
- 服务层
规则引擎架构简析 也属于一种具体实现，其中执行引擎可以看作微内核
架构实践 消息队列设计实战 知是行之始，行是知之成，知行合一。
概念
- 响应时间(Response Time)(RT)
响应时间是指系统对请求作出响应的时间。
- 吞吐量(Throughput Per Second)(TPS)
吞吐量是指系统在单位时间内处理请求的数量。
- 并发用户数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。
- 每秒查询率(Query Per Second)(QPS)
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
技术创新推动业务发展！业务发展推动技术的发展！
当规模成为业务的决定因素后，服务模式的创新就成为业务发展的核心驱动力，而产品只是为了完成服务而提供给用户使用的一个载体。
淘宝去IOE节省成本
- IBM是服务器提供商，Oracle是数据库软件提供商，EMC则是存储设备提供商。
量变带来质变
NoSQL
小文件存储
- HBase、Hadoop、Hypertable、FastDFS等都可以作为小文件存储的底层平台，只需要在这些开源方案三再包装一下基本就可以了。
典型的有：淘宝的TFS、京东的JFS、Facebook的Haystack。
大文件存储
- Google的3篇大数据论文（BigTable/MapReduce/GFS）开启了一个大数据的时代，而Yahoo开源的Hadoop系列（HDFS、HBase等），基本上垄断了开源界的大数据处理。
优选成熟的框架，避免盲目追逐技术创新！
拿来主义
- 大一点的公司可能会结合自己的业务特点做二次开发。
要知道，问题升级的同时，你的能力也在提升。
配置中心
服务中心
- 为了解决跨系统依赖的“配置”和“调度”问题。
- 实现有两种说法：服务名字系统和服务总线系统。
服务名字系统（Service Name System）
- 联想到DNS
- 将Service名称解析为“host+port+接口名称”
服务总线系统（Service Bus System）
- 总线系统完成调用，服务请求方无需直接和服务提供方交互。
消息队列
- 消息队列既可以一对一通知，也可以一对多广播。
- 成熟的开源方案：如淘宝的RocketMQ（已开源）
网络层技术
负载均衡
- DNS：地理级别的负载均衡
- Nginx&LVS&F5 同一地点内机器级别的负载均衡。
CDN
- 解决用户网络访问时“最后一公里”效应，本质上是一种“以空间换时间”的加速策略，即内容缓存在离用户最近的地方，用户访问的是缓存的内容，而不是站点实时的内容。
- 分布式存储、全局负载均衡、网络重定向、流量控制等都属于CDN的范畴。
- CDN搭建成本巨大，一般都是在供应商购买服务。
多机房、多中心
- 多中心更复杂、更自动
用户层技术
用户管理
- SSO、单点登录，如：cookie、token等。有名的开源方案：CAS
- 为了允许第三方应用的接入，“授权登陆”必不可少。
消息推送
- 海量设备和用户设备：用户与设备关联
- 连接保活：应用互相拉起、找手机厂商开白名单等
- 消息管理：灵活的逻辑设计
存储云与图片云
- 数据量大
- 文件体积小
- 访问有时效性
业务层技术
- 分久必合，合久必分。
- 高内聚，低耦合。
- 类比Facade模式。
运维平台
- 标准化、平台化、自动化、可视化
测试平台
- 用例管理、资源管理、任务管理、数据管理
数据平台
- 数据管理、数据分析、数据应用
管理平台
- 身份认证、权限控制
架构重构
- 业务已经上线，不能停下来
- 关联方众多，牵一发而动全身
- 旧架构的约束
有的放矢、切勿贪大
合纵连横
- 换位思考、合作共赢、关注长期
运筹帷幄
- 先救火、后优化、再重构。
- 分段实施：划分优先级、问题分类、先易后难。
文武全才
- 项目管理+技术能力
开源项目
- DRY：Don’t repeat yourself.不要重复造轮子。
- 选择适合的、成熟的。
- 灰度发布。谨慎使用！
聚焦运维能力
- 开源方案日志是否齐全
- 开源方案是否有命令行
- 开源方案是否有故障检测和恢复能力
- 用之前深入了解
- 小心驶得万年船，可以先在非核心业务测试
- 数据备份
开源项目的二次开发
- 保持纯洁，加以包装。节省修改成本，跟随开源项目继续演进。
发明你要的轮子
- 开源业界没有统一的标准，开发者尽兴开发。