一.互联网总统架构设计 Evergreen 2020年11月13日 架构设计 预计阅读 24 分钟 ## 1.1 互联网发展三阶段及演变 PC => 移动互联网 => 物联网(让网络协调从人扩展到万物) 互动形式演变： 1.0 内容在线，无变化，中心对多点的广播模式：`三大门户` => 2.0以互动为核心，产品有了`关注`：`微博,twitter,instagram` => 3.0群主和朋友圈，把关注一对一的关系变为了广泛的多对多：`微信,facebook` 发展的特点：业务功能越来`越多`且`复杂`，数据越来越大，请求量越来越大，用户`体验要求`越来越高，业务`快速迭代持续交付`的能力。 互联网发展架构演变：Monoliths(`单体架构`) => Horizontal(`水平分层架构`)/SOA(`面向微服务架构`) => MicroServices(`微服务架构`) => Service Meash(`服务网格架构`) ## 1.2 单体架构及水平分层架构设计与实践 单体架构图： App -> Nginx -> Tomcat [ War [StoreFrontUI，各种的服务] ] ->Mysql Database 优点：部署/测试/开发简单，可以水平扩展Tomcat中的服务。业务`场景简单`，`功能不复杂`，研发人员较少；适于创业公司初期；`性能`要求极其`苛刻`。 缺点：系统耦合性高，技术选型单一，开发效率越来越低下。 解决方式：数据库存量大问题：拆分：垂直拆分(分库)；水平拆分(分表)。架构同理：垂直方向拆分(`业务维度`)；水平方向拆分(`功能维度`)。 水平分层架构图： App -> Nginx ->网关层(GateWay) ->业务逻辑层(服务层[AccountService/InventoryService/... ]) -> 数据访问层(Dal[AccountDAO/InventoryDao/....]) -> Mysql Database 分层设计原理：展示服务与网关分离，网关与逻辑服务分离，逻辑服务与数据服务分离。 各个网关中间件对比： | 对比维度 | Zuul | SpringCloud Gateway | Nginx | Kong | Tyk | Node.js | 自研 | | -------- | ------- | ------------------- | --------- | ---------- | ------ | ----------- | -------- | | 编程语言 | Java | Java | c | c + Lua | Go | JS | Java | | 成熟度 | 高 | 低 | 高 | 高 | 高 | 高 | 高 | | 使用成本 | 低 | 较低 | 高 | 较低 | 较低 | 较低 | 低 | | IO模型 | BIO | Netty | epoll | epoll | AIO | AIO | Netty | | 技术生态 | Netflix | SpringCloud | Nginx社区 | OpenRestry | Go社区 | Node.js社区 | 公司内部 | | 适合场景 | 网关 | 网关 | 负载均衡 | 网关 | 网关 | 网关 | 网关 | 实践： 业务逻辑层功能：功能一：业务逻辑判断：案例1.微信黑名单检查，2.微信好友删除，3.微信发消息不重不漏 数据访问层功能：功能一：CRUD(增删改查接口(批量))，二.ORM(MyBatis3)，三：Sharding(分库分表Sharding-JDBC)，四.屏蔽底层存储差异性（Mysql/MongDB/Redis). 同步架构与异步架构：异步架构区别在于网关与业务逻辑层之间添加了`消息队列MQ`来异步处理。 异步架构是为了`提升吞吐量`而采用了`消息队列`，适用于`请求和业务类型`的场景。 水平分层过多：请求路径变长，平均响应延迟变高，定位问题变的复杂，运维成本增加。 水平分层过少：适合采用单体架构。 适中：同步架构(四层)：网关/业务逻辑/数据访问/数据存储层 异步架构(五层)：网关/异步消息队列/业务逻辑/数据访问/数据存储层 同步水平分层架构全貌：(DNS域名解析，静态资源获取，动态接口数据获取)：  ## 1.3 面向服务及微服务架构设计 SOA定义：组件模型；不同功能单元(服务)通过定义的良好接口关联；接口采用中立的方式定义，独立于硬件平台，操作系统和编程语言。在1996年提出，2000年逐步落地ESB，WebService，SOAP.....。架构特点是`垂直拆分`。 SOA架构：多个独立服务，通过ESB交互。企业服务总线(Enterprise Service Bus) 关联所有的服务(房产，招聘，家政服务等)，外层包含服务配置及服务治理来构建了SOA架构。 SOA缺点：业务垂直方向拆分：每个服务还是单体架构，`对ESB严重依赖`。 `微服务Microservices`：  以二手交易平台微服务架构为例：网关层：1个；业务逻辑层：多个，数据访问层：多个；DB/Cache：多个。  本质上是从两个维度进行拆分：`业务架构，组织架构`。 适用场景从三个方面考虑：需求层面，性能层面，数据一致性层面。 要达到的目的：`项目迭代快，项目持续交互`。 微服务架构不是`银弹`(所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍)：业务关注服务间"通信"，业务迭代速度变慢；基础设施组件升级困难，影响基础设施团队的交付能力和交付速度；多编程语言间"通信"问题，业务每种语言一套基础设施，成本大。 微服务结构演进：服务网格(Service Mesh)。 ## 1.4 服务网格架构设计 服务网关是最早开发Linkerd的Buoyant公司提出，并在内部使用，2016年9月29日第一次公开使用，2017年初，Service Mesh进入国内技术社区视野。 服务网格是一个`基础设施层`，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格复杂在这些拓扑中`实现请求的可靠传递`。在实践中，服务网格通常实现为一组`轻量级网络代理`，它们与应用程序部署在一起，而`对应用程序透明`。 服务网格架构   服务网格优点：Service Mesh`独立进程`，独立`升级`；业务团队`专注`于`业务逻辑`本身；一套基础设施`支持多语言`开发，业务团队和基础设施团队`物理解耦`。 开源项目(open Framework) ：`Linkerd(Scala语言)，Conduit(Rust语言)，Envoy(C++)，Nginmesh(go语言)，Istio(go/c++)` **Istio总统架构**：Istio服务网格逻辑上分为`数据面板(执行者`)和`控制面板(指挥者)`；数据面板由一组`智能代理(Envoy)`组成，代理部署为Sidecar，调解和控制微服务之间所有的网络通信；控制面板负责管理和配置代理来路由流量，以及在运行时执行策略。  **数据面板Envoy**：动态服务发现，负载均衡，TLS连接终止，HTTP/2&gRPC代理；熔断器，健康检查；基于百分比流量灰度，故障注入和丰富指标；Envoy被部署为sidecar，和对应服务在同一个Kubernetes pod中。 **Mixer**：负责在服务网格上执行访问控制和使用策略，并从Envoy代理和其他服务收集metric信息；Cnetral componet。 `Pilot`：  **Citadel**：提供强大的服务间认证和终端用户认证，使用内置身份和证书管理。 **流量控制**：请求路由：Request Routing,版本控制V1/V2  服务发现和负责均衡(Discovery & Load Balancing)：三种负责平衡模式：轮询，随机和带权重的最少请求；当给定实例的健康检查失败次数超过预定阈值时，它将从负载均衡池中弹出。当通过的健康检查次数超过预定阈值时，该实例将被添加会负责均衡池。  **流量控制/处理故障**：Envoy提供了一套开箱即用，选择加入的故障恢复功能，可以在应用长袖中受益。功能包括：超时；带超时预算有限重试以及重试之间的可变抖动；并发连接数和上游服务请求数限制；对负载均衡池的每个成员进行主动(定期)运行健康检查；细粒度熔断器(被动健康检查)，适用于负载均衡池中的每个实例。 **流量控制/错误注入**：错误配置的故障恢复策略(例如：跨服务调用的不兼容/限制性超时)可能导致应用程序中关键服务持续不可用，从而导致用户体验不佳。可以注入两种类型的故障：`延迟`和`中止`。延迟是计算时故障，模拟增加的网络延迟或者过载的上游服务。中止是模拟上游服务的崩溃故障。中止通常以HTTP错误代码或TCP连接失败的形式表现。 ## 1.5 千亿级真实案例实践 水平分层案例一：百度空间维护的推送系统。此系统用于展现好友动态，服务于百度众多的产品线(百度空间，指定，经验，旅游，ting，IM，等)。性能要求：吞吐量：100000QPS，平均响应延迟：100ms。 设计难点： Push OR Pull , 框架模式：同步 OR 异步 总体架构：  水平分层案例二：58帮帮。IM，满足58用户与商户沟通，获取信息。系统模块30+，采用JAVA/CPP。请求在10亿(IM) + 30亿(非IM)，同时在线用户突破100W+。 设计难点：千万同时在线。框架模式：同步 OR 异步 总体架构：  水平分层案例二：转转微服务 **转转微服务1.0 -> 转转微服务2.0**  **转转微服务2.0 -> 转转微服务3.0**  3.0中：抽象成公共逻辑模块： 发布业务逻辑服务，商品列表页逻辑服务，商品详情页逻辑服务，验证码逻辑服务，Push消息逻辑服务，......
评论区