网络架构

运维工作应该掌握哪些技能？ 运维中关键技术点解剖：1 大量高并发网站的设计方案 ；2 高可靠、高可伸缩性网络架构设计；3 网站安全问题，如何避免被黑？4 南北互联问题,动态CDN解决方案；5 海量数据存储架构 一、什么是大型网站运维？ 首先明确一下，全文所讲的”运维“是指：大型网站运维，与其它运维的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器 量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上亿（至少国内排名前10），如sina、baidu、 QQ， http:// 51.com 等等；其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统 、开发工作于一身的“复合性人才”，就如有些公司把一些合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责。所以，非常重要一定需要明白：运维对其它关联工种必须非常了解熟悉：网络、系统、系统开发、存储，安全,DB等；我在这里所讲的运维工程师就是指专职运维工程师。 我们再来说说一般产品的“出生”流程： 1、首先公司管理层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计。 2、架构师根据产品设计的需求，如pv大小预估、服务器规模

一个社交 App需实现的功能 用户关注的常规社交功能、活动、地理位置、探索功能、新鲜事、视频照片分享等等，需要提供的功能不胜枚举，所以从技术角度来说，开发者需要解决的问题也是异常复杂的。 当一款社交 App发布之初，用户访问量比较小，使用一台服务器就能够支撑全部的访问压力和数据存储需求，但是互联网应用具有病毒式的传播特点。一款App很可能会面临一夜爆红的现象，访问量和数据量在短时间内呈现爆发式增长，这时候会面临的局面是每天上亿PV、数百万新增用户和活跃用户、流量飙升至每秒数百兆。这些对于一个只部署了简单后端架构的应用来讲是无法支撑的，会直接导致服务器响应缓慢甚至超时，以及在高峰期时服务呈现瘫痪状态，使得后端的服务完全无法使用，用户体验急剧下降。本文将会通过一个真实的案例来分享一个社交应用如何构建一个具备高伸缩性的后端系统。 社交 App最初部署的后端架构解析 社交 App在最初的时候，后端架构相对比较简单，最初是部署在基础网络之上。最前面放置一台绑定了公网IP的nginx服务器作负载均衡，后面放置3台应用服务器来负责处理所有业务上的请求，最后面搭建一台MySQL Database数据库。 构建私有网络 随着产品的不断迭代、用户数的持续增长、数据量的积累， App就需要改进自己的后端架构，即开始构建私有网络。用户可以使用私有网络构建自己的网络拓扑——创建路由器和私有网络

一、Kubernetes是什么 Kubernetes是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。通过Kubernetes能够进行应用的自动化部署和扩缩容。在Kubernetes中，会将组成应用的容器组合成一个逻辑单元以更易管理和发现。Kubernetes积累了作为Google生产环境运行工作负载15年的经验，并吸收了来自于社区的最佳想法和实践。Kubernetes经过这几年的快速发展，形成了一个大的生态环境，Google在2014年将Kubernetes作为开源项目。Kubernetes的关键特性包括： 自动化装箱 ：在不牺牲可用性的条件下，基于容器对资源的要求和约束自动部署容器。同时，为了提高利用率和节省更多资源，将关键和最佳工作量结合在一起。 自愈能力 ：当容器失败时，会对容器进行重启；当所部署的Node节点有问题时，会对容器进行重新部署和重新调度；当容器未通过监控检查时，会关闭此容器；直到容器正常运行时，才会对外提供服务。 水平扩容 ：通过简单的命令、用户界面或基于CPU的使用情况，能够对应用进行扩容和缩容。 服务发现和负载均衡 ：开发者不需要使用额外的服务发现机制，就能够基于Kubernetes进行服务发现和负载均衡。 自动发布和回滚 ：Kubernetes能够程序化的发布应用和相关的配置。如果发布有问题，Kubernetes将能够回归发生的变更。

https://www.jianshu.com/p/193634cca86a RPC（Remote Procedure Call）：远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想。 RPC 是一种技术思想而非一种规范或协议，常见 RPC 技术和框架有： 应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。 远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。 通信框架：MINA 和 Netty。 目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。 下面重点介绍三种： gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的。不过这个对于用户来说需要学习特定领域语言这个特性，还是有一定成本的。 Dubbo

CDN网络架构主要由两大部分，分为中心和边缘两部分，中心指CDN网管中心和DNS重定向解析中心，负责全局负载均衡，设备系统安装在管理中心机房，边缘主要指异地节点，CDN分发的载体，主要由Cache和负载均衡器等组成。 当用户访问加入CDN服务的网站时，域名解析请求将最终交给全局负载均衡DNS进行处理。全局负载均衡DNS通过一组预先定义好的策略，将当时最接近用户的节点地址提供给用户，使用户能够得到快速的服务。同时，它还与分布在世界各地的所有CDNC节点保持通信，搜集各节点的通信状态，确保不将用户的请求分配到不可用的CDN节点上，实际上是通过DNS做全局负载均衡。 对于普通的Internet用户来讲，每个CDN节点就相当于一个放置在它周围的WEB。通过全局负载均衡DNS的控制，用户的请求被透明地指向离他最近的节点，节点中CDN服务器会像网站的原始服务器一样，响应用户的请求。由于它离用户更近，因而响应时间必然更快。 每个CDN节点由两部分组成：负载均衡设备和高速缓存服务器 负载均衡设备负责每个节点中各个Cache的负载均衡，保证节点的工作效率；同时，负载均衡设备还负责收集节点与周围环境的信息，保持与全局负载DNS的通信，实现整个系统的负载均衡。 高速缓存服务器（Cache）负责存储客户网站的大量信息，就像一个靠近用户的网站服务器一样响应本地用户的访问请求。

一、c/s架构和b/s架构 c/s架构：客户端和服务器 eg：QQ、微信 c端-----------------------网络---------------------s端 c端：就是客户端 s端：有固定IP，并且稳定一直在运行，支持高并发 b/s架构：浏览器和服务器 eg：京东、天猫 其实b/s架构的本质也是c/s架构 二、网络协议 什么是网络？ 网络就是网络连接介质+网络协议 网络协议 OSI七层协议：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层 OSI五层协议：物理层、数据链路层、网络层、传输层、应用层 2.1 物理层 主要是010101的高低压电信号 2.2 数据链路层 通过etherner协议（以太网协议，，定义了以太网的分组方式）把物理层的电信号分组，每一组叫一个数据报/数据帧。 每一数据帧分成报头head和数据data两部分。 | 报头(18字节) | data(46-1500) | ​ 报头(固定18字节)：发送者占6位，接收者占6位，数据类型占6位 mac地址 ：发送者，接收者地址，就是mac地址，每个网卡都有一个唯一的mac地址，总长度为48位2进制，12位16进制数表示（前六位是厂商编号，后六位是流水线号） 广播：同一个局域网内通信，会出现广播风暴 2.3 网络层 IP：主要有IPV4和IPV6 IPV4:32位2进制,用点分十进制表示

早期的计算机通信需要有一个中间件,A要给B传东西,A必须要把信息传给中间件,B再把从中间件中拿到信息 由于不同机器之间需要通信就产生了网络 软件开发的架构 1.C/S架构 服务器-客户机,即Client-Server架构,C/S架构通常采取两层结构.Sever负责数据的管理,Client负责完成与用户的交互任务 这里来说Client主要是某个应用软件的exe文件,程序要在安装后,才能运行在用户电脑上。 例如:QQ、微信、网易云音乐等 2.B/S架构 浏览器端-服务器,即Browser-Sever,B/S架构是WEB兴起后的一种网络架构模式,WEB浏览器是客户端最主要的应用软件.这种模式统一了客户端,将系统功能实现的核心部分集中到服务器上,简化了系统的开发、维护和使用.客户机上只要安装一个Browser,服务器安装Oracle、SQL Sever等数据库.浏览器通过Web Sever同数据库进行数据交互,这样就大大简化了客户端电脑载荷,减轻了系统维护与升级的成本和工作量,降低了用户的总体成本(TCO)。 例如:百度、知乎、豆瓣、博客园等 3.B/S架构和C/S架构之间的关系 B/S架构是C/S架构的一种 计算机网络的发展及基础网络概念 早期:联机 想要实现通信就必须要网卡和网线,每个网卡上都有一个全球唯一的MAC地址 MAC地址 :英文名为Media Access Control

OpenStack既是一个社区，也是一个项目和一个开源软件，提供开放源码软件，建立公共和私有云，它提供了一个部署云的操作平台或工具集，其宗旨在于：帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。 OpenStackd开源项目由社区维护，包括OpenStack计算（代号为Nova），OpenStack对象存储（代号为Swift），并OpenStack镜像服务（代号Glance）的集合。 OpenStack提供了一个操作平台，或工具包，用于编排云。 下面列出Openstack的详细构架图 Openstack的网络拓扑结构图 整个OpenStack是由控制节点，计算节点，网络节点，存储节点四大部分组成。（这四个节点也可以安装在一台机器上，单机部署） 其中： 控制节点负责对其余节点的控制，包含虚拟机建立，迁移，网络分配，存储分配等等 计算节点负责虚拟机运行 网络节点负责对外网络与内网络之间的通信 存储节点负责对虚拟机的额外存储管理等等 控制节点架构： 控制节点包括以下服务 管理支持服务 基础管理服务 扩展管理服务 1）管理支持服务包含MySQL与Qpid两个服务 MySQL：数据库作为基础/扩展服务产生的数据存放的地方 Qpid：消息代理(也称消息中间件)为其他各种服务之间提供了统一的消息通信服务 2）基础管理服务包含Keystone

C/S结构网络开发与B/S结构网络开发认识 C/S结构网络开发:如QQ客户端的登录界面 B/S结构网络开发:网页的客户端登录界面 2.C/S结构与B/S的差别 第一、什么是C/S结构。 C/S （Client/Server）结构，即大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server 应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。 传统的C／S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。由于没能提供用户真正期望的开放环境，C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件， 加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。而且代价高， 效率低。 第二、什么是B/S结构。 B/S（Browser/Server）结构即浏览器和服务器结构

这是关于使用微服务架构创建应用系列的第四篇文章。第一篇介绍了微服务架构的模式，讨论了使用微服务架构的优缺点。第二和第三篇描述了微服务架构内部的通讯机制。这篇文章中，我们将会探讨服务发现相关问题。 为什么要使用服务发现? 设想一下，我们正在写代码使用了提供REST API或者Thrift API的服务，为了完成一次服务请求，代码需要知道服务实例的网络位置（IP地址和端口）。传统应用都运行在物理硬件上，服务实例的网络位置都是相对固定的。例如，代码可以从一个经常变更的配置文件中读取网络位置。 而对于一个现代的，基于云微服务的应用来说，这却是一个很麻烦的问题。其架构如图所示： 服务实例的网络位置都是动态分配的，而且因为扩展、失效和升级等需求，服务实例会经常动态改变，因此，客户端代码需要使用一种更加复杂的服务发现机制。 目前有两大类服务发现模式： 客户端发现 和 服务端发现 。 我们先来来讨论一下客户端发现。 客户端发现模式 当使用 客户端发现模式 时，客户端负责决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端从一个服务注册服务中查询，其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。 下图显示的是这种模式的架构图： 服务实例的网络位置是在启动时注册到服务注册表中，并且在服务终止时从注册表中删除