分布式部署

美团外卖从2013年9月成交第一单以来，已走过了三个年头。期间，业务飞速发展，美团外卖由日均几单发展为日均500万单（9月11日已突破600万）的大型O2O互联网外卖服务平台。平台支持的品类也由最初外卖单品拓展为全品类。 随着订单量的增长、业务复杂度的提升，外卖订单系统也在不断演变进化，从早期一个订单业务模块到现在分布式可扩展的高性能、高可用、高稳定订单系统。整个发展过程中，订单系统经历了几个明显的阶段，下面本篇文章将为大家介绍一下订单系统的演进过程，重点关注各阶段的业务特征、挑战及应对之道。 为方便大家更好地了解整个演进过程，我们首先看一下外卖业务。 外卖订单业务 外卖订单业务是一个需要即时送的业务，对实时性要求很高。从用户订餐到最终送达用户，一般在1小时内。如果最终送达用户时间变长，会带来槽糕的用户体验。在1小时内，订单会快速经过多个阶段，直到最终送达用户。各个阶段需要紧密配合，确保订单顺利完成。 下图是一个用户视角的订单流程图： 从普通用户的角度来看，一个外卖订单从下单后，会经历支付、商家接单、配送、用户收货、售后及订单完成多个阶段。以技术的视角来分解的话，每个阶段依赖于多个子服务来共同完成，比如下单会依赖于购物车、订单预览、确认订单服务，这些子服务又会依赖于底层基础系统来完成其功能。 外卖业务另一个重要特征是一天内订单量会规律变化，订单会集中在中午、晚上两个“饭点”附近

本文链接：https://blog.csdn.net/m0_38125278/article/details/95046242 分布式架构的架构稳定性 接上一期架构性能，本期讲架构稳定性 1.服务拆分 服务拆分主要有两个目的：一是为了隔离故障，二是为了重用服务模块。但服务拆分完之后，会引入服务调用间的依赖问题。 2.服务冗余 服务冗余是为了去除单点故障，并可以支持服务的弹性伸缩，以及故障迁移。然而，对于一些有状态的服务来说，冗余这些有状态的服务带来了更高的复杂性。其中一个是弹性伸缩时，需要考虑数据的复制或是重新分片，迁移的时候还要迁移数据到其它机器上。 3.限流降级 当系统实在扛不住压力时，只能通过限流或者功能降级的方式来停掉一部分服务，或是拒绝一部分用户，以确保整个架构不会挂掉。这些技术属于保护措施。 4.高可用架构 通常来说高可用架构是从冗余架构的角度来保障可用性。比如，多租户隔离，灾备多活，或是数据可以在其中复制保持一致性的集群。总之，就是为了不出单点故障。 4.高可用运维 高可用运维指的是 DevOps 中的 CI/CD（持续集成 / 持续部署）。一个良好的运维应该是一条很流畅的软件发布管线，其中做了足够的自动化测试，还可以做相应的灰度发布，以及对线上系统的自动化控制。这样，可以做到“计划内”或是“非计划内”的宕机事件的时长最短。 上述这些技术非常有技术含量

前言：可能是大佬都觉得简单吧都没有详细的介绍(有介绍，可能是我太小白看不懂，哈哈哈)，捉摸了一段时间把大佬们的文档记录下： 一、各服务器命名和作用（摘自：ET社区） 服务器名称 Manager : 对服务器进程进行管理Realm : 登录服务器 ( 验证账号密码 相当于LoginServer 祖传叫法,你想叫什么随你) Gate : 网关服务器 DB : 数据库服务器 Location : 位置服务器 Map : 地图服务器 Client : 客户端 All Server: 所有服务器集合 各服务器的作用(摘录自文档ET框架笔记): Manager：连接客户端的外网和连接内部服务器的内网，对服务器进程进行管理，自动检测和启动服务器进程。加载有内网组件NetInnerComponent，外网组件NetOuterComponent，服务器进程管理组件。自动启动突然停止运行的服务器，保证此服务器管理的其它服务器崩溃后能及时自动启动运行。 Realm：对Actor消息进行管理（添加、移除、分发等），连接内网和外网，对内网服务器进程进行操作，随机分配Gate服务器地址。内网组件NetInnerComponent，外网组件NetOuterComponent，Gate服务器随机分发组件。客户端登录时连接的第一个服务器，也可称为登录服务器。 Gate：对玩家进行管理，对Actor消息进行管理（添加

K8S+GitLab-自动化分布式部署ASP.NET Core(二) ASP.NET Core DevOps K8S+GitLab-自动化分布式部署ASP.NET Core(二) ASP.NET Core DevOps 一.介绍 前一篇, 写的K8S部署环境的文章 ,简单的介绍下DevOps（Development和Operations的组合词）,高效交付, 自动化流程,来减少软件开发人员和运维人员的沟通。Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。" 下面正式开始部署ASP.NET Core 项目. 二.正式部署ASP.NET Core项目 GitHub地址: https://github.com/gyw1309631798/Deploy-API . 我创建了一个ASP.NET Core 2.1 WebAPI项目 里面包含了deploy.yaml,Dockerfile文件. 要在K8S上部署首先要添加 regsecret ,不然从Harbor pull会失败. kubectl create namespace netcore (创建命名空间)kubectl create secret docker-registry regsecretlocal --namespace=netcore --docker-server=192.168.0

1.缓存概述 ​ 缓存是分布式系统中的重要组件，主要解决高并发，大数据场景下，热点数据访问的性能问题。提供高性能的数据快速访问。 1.1.缓存的原理 将数据写入/读取速度更快的存储（设备）； 将数据缓存到离应用最近的位置； 将数据缓存到离用户最近的位置; 1.2.缓存分类 在分布式系统中，缓存的应用非常广泛，从部署角度有以下几个方面的缓存应用： - CDN缓存； - 反向代理缓存； - 分布式Cache； - 本地应用缓存； 1.3.缓存媒介 常用中间件：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等； 缓存的内容：文件，数据，对象； 缓存的介质：CPU，内存（本地，分布式），磁盘（本地，分布式） 1.4.缓存设计 缓存设计需要解决以下几个问题： 1>缓存什么？哪些数据需要缓存：1.热点数据；2.静态资源。 2>缓存的位置？CDN，反向代理，分布式缓存服务器，本机（内存，硬盘） 3>如何缓存的问题？ - 过期策略 - 固定时间：比如指定缓存的时间是30分钟； - 相对时间：比如最近10分钟内没有访问的数据； - 同步机制 - 实时写入；（推） - 异步刷新；（推拉） 2.CDN缓存 ​ CDN主要解决将数据缓存到离用户最近的位置，一般缓存静态资源文件（页面，脚本，图片，视频，文件等）。国内网络异常复杂，跨运营商的网络访问会很慢

大数据技术栈 Hadoop 历史： https://www.jikexueyuan.com/course/677_1.html?ss=1 1. Google大数据与Hadoop对比 功能 Google Hadoop 存储 GFS HDFS 计算 MapReduce MapReduce 查询 BigTable HBase 2. 大数据分类 2.1 根据数据类型分类 2.1.1 结构化数据 能够用数据或统一的结构加以表示，人们称之为结构化数据，如数字、符号。传统的关系数据模型，行数据，存储于数据库，可用二维表结构表示。 2.1.2 半结构化数据 所谓半结构化数据，就是介于完全结构化数据（如关系型数据库，面向对象数据库中的数据）和完全无结构的数据（如声音、图像文件等）之间的数据，XML、HTML文档就属于半结构化数据。它一般是自描述的，数据的结构和内容混在一起，没有明显的区分。 2.1.3 非结构化数据 非结构化数据库是指其字段长度可变，并且每隔字段的记录又可以由可重复或不可重复的子字段构成的数据库，用它不仅可以处理结构化数据（如数字、符号等信息）而且更适合处理非结构化数据（全文文本，图像，声音，影视，超媒体等信息）。 参考链接： https://zhidao.baidu.com/question/589302455243618045.html 2.2 根据处理时间跨度要求分类 2.2

1. Dubbo是什么？ Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架 其核心部分包含: 1. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。 2. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。3. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 2. Dubbo能做什么？ 1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可

　Zookeeper是hadoop的一个子项目，虽然源自hadoop，但是我发现zookeeper脱离hadoop的范畴开发分布式框架的运用越来越多。今天我想谈谈zookeeper，本文不谈如何使用zookeeper，而是zookeeper到底有哪些实际的运用，哪些类型的应用能发挥zookeeper的优势，最后谈谈zookeeper对分布式网站架构能产生怎样的作用。 　　Zookeeper是针对大型分布式系统的高可靠的协调系统。由这个定义我们知道zookeeper是个协调系统，作用的对象是分布式系统。为什么分布式系统需要一个协调系统了？理由如下： 　　开发分布式系统是件很困难的事情，其中的困难主要体现在分布式系统的“部分失败”。“部分失败”是指信息在网络的两个节点之间传送时候，如果网络出了故障，发送者无法知道接收者是否收到了这个信息，而且这种故障的原因很复杂，接收者可能在出现网络错误之前已经收到了信息，也可能没有收到，又或接收者的进程死掉了。发送者能够获得真实情况的唯一办法就是重新连接到接收者，询问接收者错误的原因，这就是分布式系统开发里的“部分失败”问题。 　　Zookeeper就是解决分布式系统“部分失败”的框架。Zookeeper不是让分布式系统避免“部分失败”问题，而是让分布式系统当碰到部分失败时候，可以正确的处理此类的问题，让分布式系统能正常的运行。 　

#0 系列目录# 大型分布式网站架构 大型分布式网站架构技术总结 大型网站架构系列：电商网站架构案例 #1 电商案例原因# 分布式大型网站，目前看主要有几类1.大型门户，比如网易，新浪等；2.SNS网站，比如校内，开心网等；3.电商网站：比如阿里巴巴，京东商城，国美在线，汽车之家等。 大型门户一般是新闻类信息，可以使用CDN，静态化等方式优化 ， 开心网等交互性比较多，可能会引入更多的NOSQL，分布式缓存，使用高性能的通信框架等 。电商网站具备以上两类的特点， 比如产品详情可以采用CDN，静态化，交互性高的需要采用NOSQL等技术 。因此，我们采用电商网站作为案例，进行分析。 #2 电商网站需求# 客户需求： 建立一个全品类的电子商务网站（B2C），用户可以在线购买商品，可以在线支付，也可以货到付款； 用户购买时可以在线与客服沟通； 用户收到商品后，可以给商品打分，评价； 目前有成熟的进销存系统；需要与网站对接； 希望能够支持3~5年，业务的发展； 预计3~5年用户数达到1000万； 定期举办双11，双12,三八男人节等活动； 其他的功能参考京东或国美在线等网站。 客户就是客户，不会告诉你具体要什么，只会告诉你他想要什么，我们很多时候要引导，挖掘客户的需求。好在提供了明确的参考网站。因此，下一步要进行大量的分析，结合行业，以及参考网站，给客户提供方案。 需求管理传统的做法

一、电商案例的原因 分布式大型网站，目前看主要有几类1.大型门户，比如网易，新浪等；2.SNS网站，比如校内，开心网等；3.电商网站：比如阿里巴巴，京东商城， 国美在线，汽车之家等。大型门户一般是新闻类信息，可以使用CDN，静态化等方式优化，开心网等交互性比较多，可能会引入更多的NOSQL，分布式缓存， 使用高性能的通信框架等。电商网站具备以上两类的特点，比如产品详情可以采用CDN，静态化，交互性高的需要采用NOSQL等技术。因此，我们采用电商网 站作为案例，进行分析。 二、电商网站需求 客户需求： 建立一个全品类的电子商务网站（B2C），用户可以在线购买商品，可以在线支付，也可以货到付款； 用户购买时可以在线与客服沟通； 用户收到商品后，可以给商品打分，评价； 目前有成熟的进销存系统；需要与网站对接； 希望能够支持3~5年，业务的发展； 预计3~5年用户数达到1000万； 定期举办双11，双12,三八男人节等活动； 其他的功能参考京东或国美在线等网站。 客户就是客户，不会告诉你具体要什么，只会告诉你他想要什么，我们很多时候要引导，挖掘客户的需求。好在提供了明确的参考网站。因此，下一步要进行大量的分析，结合行业，以及参考网站，给客户提供方案。 其他的略~~~~~ 需求功能矩阵 需求管理传统的做法，会使用用例图或模块图（需求列表）进行需求的描述。这样做常常忽视掉一个很重要的需求