运维知识体系
-
客户端层
-
浏览器
Cookie作用域、浏览器缓存协商（Last-Modified、Expires、Etag）、组件分离、前端优化、运维检测工具
-
Cookie作用域：浏览器提交的Cookie需要满足以下两点才会被提交
-
- 当前域名或者父域名下的Cookie（Domain）
-
- 当前路径或父路径下的Cookie（Path）
-
-
浏览器缓存
-
强制缓存：浏览器不会像服务器发送任何请求，直接从本地缓存中读取文件并返回Status Code: 200 OK；优先访问memory cache，其次是disk cache，最后是请求网络资源
-
Expires：过期时间，如果设置了时间，则浏览器会在设置的时间内直接读取缓存，不再请求
-
Cache-Control：
- （1） max-age：用来设置资源（representations）可以被缓存多长时间，单位为秒；
- （2） s-maxage：和max-age是一样的，不过它只针对代理服务器缓存而言；
- （3）public：指示响应可被任何缓存区缓存；
- （4）private：只能针对个人用户，而不能被代理服务器缓存；
- （5）no-cache：强制客户端直接向服务器发送请求,也就是说每次请求都必须向服务器发送。服务器接收到请求，然后判断资源是否变更，是则返回新内容，否则返回304，未变更。这个很容易让人产生误解，使人误以为是响应不被缓存。实际上no-cache是会被缓存的，只不过每次在向客户端（浏览器）提供响应数据时，缓存都要向服务器评估缓存响应的有效性。
- （6）no-store：禁止一切缓存（这个才是响应不被缓存的意思）。
-
-
协商缓存：向服务器发送请求，服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存，如果命中，则返回304状态码并带上新的response header通知浏览器从缓存中读取资源
-
Last-Modifed/If-Modified-Since（HTTP 1.0）
- 浏览器向服务器发送资源最后的修改时间
- 当资源过期时（浏览器判断Cache-Control标识的max-age过期），发现响应头具有Last-Modified声明，则再次向服务器请求时带上头if-modified-since，表示请求时间。服务器收到请求后发现有if-modified-since则与被请求资源的最后修改时间进行对比（Last-Modified），若最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；若最后修改时间较旧（小），说明资源无新修改，响应HTTP 304 走缓存。
-
Etag/If-None-Match（HTTP 1.1，Etag优先级是高于Last-Modifed的，所以服务器会优先验证Etag）
- Etag：它是由服务器（Apache或者其他工具）生成返回给前端，用来帮助服务器控制Web端的缓存验证。Apache中，ETag的值，默认是对文件的索引节（INode），大小（Size）和最后修改时间（MTime）进行Hash后得到的。
- If-None-Match：当资源过期时，浏览器发现响应头里有Etag，则再次像服务器请求时带上请求头if-none-match(值是Etag的值)。服务器收到请求进行比对，决定返回200或304
-
-
-
组件分离
-
前端优化
-
运维检测工具
-
-
DNS
Domain Name System，域名系统；浏览器DNS缓存、DNS缓存、自建DNS服务器、商业DNS产品、智能DNS、公共DNS（BGP anycast）、bind+DLZ/DPDK
-
DNS缓存
-
查询顺序：浏览器缓存→系统缓存→路由器缓存→ISP DNS 缓存→递归搜索
-
常见类型
-
浏览器DNS缓存：chrome对每个域名会默认缓存60s（chrome://net-internals/#dns 可以看各域名的DNS 缓存时间）
-
系统缓存：Windows DNSClient（ipconfig /displaydns）
-
ISP缓存
- 1、本身是一种宽带接入提供商给网页批量访问加速的技术。ISP会将当前访问量较大的网页内容放到ISP服务器的缓存中，当有新的用户请求相同内容时，可以直接从缓存中发送相关信息，不必每次都去访问真正的网站，从而加快了不同用户对相同内容的访问速度，同时也能节省网间流量结算成本。
- 2、ISP缓存主要以缓存静态页面为主，比如新浪的新闻页。
- 3、 如果ISP的缓存中的网页带有用户SESSIONID信息，就可能发生登录串号现象。当用户A登录时服务端返回页面内容被ISP缓存，这时同网络的用户B访问该网站，直接取得了刚才ISP缓存的信息，而该缓存信息中包含有用户A的SESSIONID（此时用户A还未退出），这样用户B处就显示出了A的信息。
-
-
-
自建DNS服务器
-
商业DNS产品
- 阿里云DNS等
-
智能DNS
智能DNS是域名服务在业界首创的智能解析服务。能自动判断访问者的IP地址并解析出对应的IP地址，使网通用户会访问到网通服务器，电信用户会访问到电信服务器。 如果电信的LocalDNS对非自家ip的访问限了速那么很明显会影响你的DNS解析时间。
-
公共DNS（BGP anycast）
- IBM 的 9.9.9.9 ，** Google 的 ** 8.8.8.8 / 8.8.4.4*，*OpenDNS；国内114.114.114.114 / 114.114.115.115
-
bind+DLZ/DPDK
-
缺陷
- 域名劫持
- 缓存更新不及时
- 转发解析（智能DNS的优势）
-
-
客户端/APP
HTTP-DNS、打点日志、加密传输、移动推送、各类SDK（监控SDK、推流SDK等）
-
HTTP-DNS
使用HTTP与DNS服务器交互，代替传统的基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务端，从而绕过运营商的Local DNS
-
原理图
-
优势
- 防止域名劫持
- 精准调度，能够直接获取到用户的IP地址，从而实现精确定位与导流
- 用户连接失败率下降
-
-
打点日志
-
加密传输
-
移动推送
-
各类SDK（监控SDK、推流SDK等）
-
-
-
外部层
-
外部CDN
GSLB、反向代理缓存、分布式存储、流量调度、配置管理、用户端（各类API如：带宽监控、预缓存、缓存刷新）
-
GSLB
-
定义：Global Server Load Balancing （全局负载均衡）
-
特点：
- 高可用
- 更快响应
- 多版本发布
-
实现方式：
- DNS解析（侵入性小，得不到源IP；商业ADC）
- HTTP 重定向（只适用于HTTP；Nginx、HTTPD）
- IP Route（解决不能获得源IP和HTTP Only的问题）
- 统一调度服务层（客户端SDK+调度服务完成GSLB设备的功能，服务端可以获得任何想要知道的信息，侵入性最大）
-
-
代理
-
正向代理：正向代理，目标服务器不知道谁在访问
-
反向代理：用户实际并不知道最终服务器，只是访问一个反向代理服务器而已（安全，负载均衡，缓存）
-
nginx配置
- proxy_pass：反向代理
- upstream：负载均衡（默认轮询，权重weight，固定ip_hash解决 session 共享，第三方模块fair等）
- proxy_store：永久缓存配置
- proxy_cache：临时缓存
-
-
分布式存储
-
集中式存储基本架构
集中式存储最大的特点是有一个统一的入口，所有数据都要经过这个入口，这个入口就是存储系统的机头。
-
中间控制节点架构（HDFS）
在该系统的整个架构中将服务器分为两种类型，一种名为namenode，这种类型的节点负责管理管理数据（元数据），另外一种名为datanode，这种类型的服务器负责实际数据的管理。
-
完全无中心架构---计算模式（Ceph）
如图是Ceph存储系统的架构，在该架构中与HDFS不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系计算出来其写入数据的位置，这样客户端可以直接与存储节点通信，从而避免中心节点的性能瓶颈。
-
完全无中心架构---一致性哈希（Swift）
一致性哈希的方式就是将设备做成一个哈希环，然后根据数据名称计算出的哈希值映射到哈希环的某个位置，从而实现数据的定位。 在Swift对象存储中，通过账户名/容器名/对象名三个名称组成一个位置的标识，通过该唯一标识可以计算出一个整型数来。这样，Swift就可以将请求重新定向到该设备进行处理。
-
-
流量调度
-
如何将庞大大的访问流量合理分配到分布在各地的CDN边缘节点。
-
-
预缓存和缓存刷新
- 缓存刷新：提交缓存刷新请求后，CDN节点的缓存内容将会被强制过期。当用户向CDN节点请求资源时，CDN会直接回源站拉取对应的资源返回给用户，并将其缓存。
- 缓存预热：提交缓存预热请求后，源站将会主动将对应的资源缓存到CDN节点。当用户首次请求时，就能直接从CDN节点缓存中获取到最新的请求资源，无需再回源站拉取。
-
-
外部安全防护
第三方安全解决方案（防DDOS、防CC攻击、WAF等）
-
DDOS
-
定义：Distributed Denial of Service，分布式拒绝服务。对目标网站在较短的时间内发起大量请求，大规模消耗目标网站的主机资源，让它无法正常服务。
-
防范
- 高仿服务器
- 黑名单
- DDOS清洗：对用户请求数据进行实时监控，及时发现DOS攻击等异常流量，在不影响正常业务开展的情况下清洗掉这些异常流量。
- CDN加速：分散攻击风险
-
-
CC
-
定义：Challenge Collapsar，挑战黑洞。CC攻击的原理是通过代理服务器或者大量肉鸡模拟多个用户访问目标网站的动态页面，制造大量的后台数据库查询动作，消耗目标CPU资源，造成拒绝服务。
因为以前的抵抗DDoS攻击的安全设备叫黑洞，顾名思义挑战黑洞就是说黑洞拿这种攻击没办法，新一代的抗DDoS设备已经改名为ADS(Anti-DDoS System)，基本上已经可以完美的抵御CC攻击了
-
防范：尽量少用动态网页并且让一些操作提供验证码就能抵御一般的CC攻击
-
区别：DDoS是针对IP的攻击，而CC攻击的是服务器资源
-
-
WAF
- 定义：Web Application Firewall，由于传统防火墙无法对应用层的攻击进行有效抵抗，并且IPS也无法从根本上防护应用层的攻击，因此出现了保护Web应用安全的Web应用防火墙系统(简称“WAF”)。WAF是一种基础的安全保护模块，通过特征提取和分块检索技术进行特征匹配，主要针对 HTTP 访问的 Web 程序保护。WAF部署在Web应用程序前面，在用户请求到达 Web 服务器前对用户请求进行扫描和过滤，分析并校验每个用户请求的网络包，确保每个用户请求有效且安全，对无效或有攻击行为的请求进行阻断或隔离
- 功能：拦截入侵尝试，比如SQL Injection、 XSS、 路径遍历、 窃取敏感数据、CC攻击等
-
-
-
网络层
-
互联层
-
多机房互联
-
异地灾备：异地备份，通过互联网TCP/IP协议，将本地的数据实时备份到异地服务器中，可以通过异地备份的数据进行远程恢复，也可以在异地进行数据回退，异地备份，如果想做接管需要专线连接，只有在同一网段内才能实现业务的接管
-
异地多活：异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑
-
分set部署：把一定号段的用户路由到某个一组指定的服务中，而这一组服务就是常说的set，固然一个set的设计需要考虑许多不同的因素，但一个n+1的set冗余部署在某些业务也是一个较经济的部署策略
-
-
核心层
-
防火墙
指设置在不同网络（如可信任的企业内部网和不可信的公共网）或网络安全域之间的一系列部件的组合。它可以通过监测、限制、更改跨越防火墙的数据流，尽可能地对外部屏蔽网络内部的信息、结构和运行状况，以此来实现网络的安全保护。在逻辑上，防火墙是一个分离器，一个限制器，也是一个分析器，有效地监控了内部网和Internet之间的任何活动，保证了内部网络的安全
-
路由器
-
Ipsec VPN
指采用IPSec协议来实现远程接入的一种VPN技术，IPSec全称为Internet Protocol Security，是由Internet Engineering Task Force (IETF) 定义的安全标准框架，在公网上为两个私有网络提供安全通信通道,通过加密通道保证连接的安全——在两个公共网关间提供私密数据封包服务
-
链路负载均衡
服务器负载均衡是将客户端请求在集群中的服务器上实现均衡分发的技术， 链路负载均衡是指通过动态算法在多条网络链路中进行负载均衡根据业务流量的方向可以分为Outhound链路负载均衡和Inbound链路负载均衡两种情况
-
Outbound链路负载均衡：主要解决的是企业内部业务系统访问外部互联网服务时如何在多条不同的链路中动态分配和负载均衡的问题
(1)负载均衡设备：负责将内网到外网的流量在多条物理链路上分发。 (2)物理链路：网络服务器提供商(ISP)提供的实际通信链路。 (3)虚拟IP地址：负载均衡设备对外提供的虚拟IP地址，用做用户发送报文的目的地址。 用户在将访问虚拟IP地址的报文发送给负载均衡设备后，负载均衡设备通过链路选择算法选择出最佳的物理链路，并将内网访问外网的业务流量分发到该链路上。
-
Inbound链路负载均衡：主要解决的是位于互联网外部的用户如何在访同企业内部网站和业务系统时动态地在多条链路上平衡分配，并在一条链路中断时能够智能地自动切换到另一条可用链路
原理是将负载均衡设备作为权威名称服务器，用于记录域名与内网服务器IP地址之间的映射关系
-
-
高可用
-
-
汇聚层
-
三层交换
-
动态路由
-
静态路由
-
EC（端口汇聚）
-
路由交换
- VRRP：一种容错协议，可以实现下一跳网关设备的备份，当连接主机的下一跳网关设备出现故障时，由网络中另一台设备代替故障设备进行工作，从而保证网络通信的连续性和可靠性
- MSTP：多生成树协议（Multiple Spanning Tree Protocol）将环路网络修剪成为一个无环的树型网络，避免报文在环路网络中的无限循环，同时还提供了数据转发的多个冗余路径，在数据转发过程中实现VLAN数据的负载均衡
-
-
接入层
-
二层交换
- VTP
- SPF
- Trunk
- 端口安全
-
-
-
接入层
-
负载均衡高可用
OSI（Open System Interconnection）七层参考模型，是参考模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系。它从低到高分别是：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。四层工作在OSI第四层，也就是传输层；七层工作在最高层，也就是应用层。
-
四层负载均衡：使用IP加端口的方式进行路由转发
- 原理：通过报文中的IP地址和端口，再加上负载均衡设备所采用的负载均衡算法，最终确定选择后端哪台下游服务器。以TCP为例，客户端向负载均衡发送SYN请求建立第一次连接，通过配置的负载均衡算法选择一台后端服务器，并且将报文中的IP地址信息修改为后台服务器的IP地址信息，因此TCP三次握手连接是与后端服务器直接建立起来的
- 安全性：与服务器直接建立起TCP连接，很容易遭受SYN Flood攻击。SYN Flood是一种广为人知的DDoS（分布式拒绝服务攻击）的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽的攻击方式。从技术实现原理上可以看出，四层负载均衡很容易将垃圾流量转发至后台服务器
- 常见设备：开源：LVS（IP负载均衡）+Keepalived、Haproxy 商业：F5、Netscaler
-
七层负载均衡：基于请求URL地址的方式进行代理转发
- 原理：在应用层选择服务器，只能先与负载均衡设备进行TCP连接，然后负载均衡设备再与后端服务器建立另外一条TCP连接通道。因此，七层设备在网络性能损耗会更多一些
- 安全性：可以过滤并清洗恶意流量，但要求设备本身具备很强的抗DDOS流量的能力
- 常见：Haproxy、Nginx、Apache（根据HTTP协议支持的属性进行L7分发）、A/B Test Gateway、WAF
-
其他：基于MAC地址信息(虚拟MAC地址到真实MAC地址)进行转发的二层负载均衡和基于IP地址(虚拟IP到真实IP)的三层负载均衡
-
-
反向代理缓存
- ATS、Squid、Varnish、Nginx(缓存分级、预缓存、缓存刷新）
-
-
应用服务层
-
Web服务层
-
HTTP协议
-
Web服务器
- Apache
- Nginx/OpenResty
- Tomcat
- Resin
- Jboss
-
性能优化
-
-
应用服务层
-
运行环境（PHP、Python、Java、C、C++）
-
性能优化
-
缓存（OPCache、LocalCache）
-
Session存储
-
session存放在服务器端的内存中（Tomcat）或文件中（PHP）。不过session可以通过特殊的方式做持久化管理（memcache，redis）。
session不会因为浏览器的关闭而删除。但是存有session ID的cookie的默认过期时间是会话级别。也就是用户关闭了浏览器，那么存储在客户端的session ID便会丢失，但是存储在服务器端的session数据并不会被立即删除。从客户端即浏览器看来，好像session被删除了一样（因为我们丢失了session ID，找不到原来的session数据了）。
-
-
代码部署
-
-
业务层
-
业务实现
-
API网关
-
网关
-
应用
-
-
Open API
企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开放平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。
-
微服务网关
微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。 在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。
-
API服务管理平台
上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。 API网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的API服务管理平台。
-
-
方案
-
私有云开源解决方案如下：
- Kong kong是基于Nginx+Lua进行二次开发的方案， konghq.com/
- Netflix Zuul，zuul是spring cloud的一个推荐组件，github.com/Netflix/zuu…
- orange,这个开源程序是国人开发的， orange.sumory.com/
-
公有云解决方案：
- Amazon API Gateway，ateway/
- 阿里云API网关，ateway/
- 腾讯云API网关， ct/apigateway
-
自开发解决方案：
- 基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于这个方案
- 基于Netty、非阻塞IO模型。 通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案，是一种成熟的方案。
- 基于Node.js的方案。 这种方案是应用了Node.js天生的非阻塞的特性。
- 基于java Servlet的方案。 zuul基于的就是这种方案，这种方案的效率不高，这也是zuul总是被诟病的原因。
-
-
选型
-
1、性能与可用性
如果一旦采用了API网关，那么API网关就会作为企业应用核心，因此性能和可用性是必须要求的。 从性能上来说，需要让网关增加的时间消耗越短越好，个人觉得需要10ms以下。系统需要采用非阻塞的IO，如epoll，NIO等。网关和各种依赖的交互也需要是非阻塞的，这样才能保证整体系统的高可用性，如：Node.js的响应式编程和基于java体现的RxJava和Future。 网关必须支持集群部署，任务一台服务器的crash都应该不影响整体系统的可用性。 多套网关应该支持同一管理平台和同一监控中心。如：一个企业的OpenAPI网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。
-
2、可扩展性、可维护性
一款产品总有不能满足生产需求的地方，因此需求思考产品在如何进行二次开发和维护，是否方便公司团队接手维护产品。
-
3、需求匹配度
需要评估各API网关在需求上是否能满足，如：如果是OpenAPI平台需要使用API网关，那么需要看API网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OpenAPI核心需求上去思考产品是否能满足要求。如果是微服务网关，那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。
-
4、是否开源？公司是否有自开发的能力？
现有的开源产品如kong，zuul，orange都有基础的API网关的核心功能，这些开源产品大多离很好的使用有一定的距离，如：没有提供管理功能的UI界面、监控功能弱小，不支持OpenAPI平台，没有公司运营与运维的功能等。当然开源产品能获取源代码，如果公司有比较强的研发能力，能hold住这些开源产品，经过二次开发kong、zuul应该还是适应一些公司，不过需求注意以下一些点： kong是基于ngnix+lua的，从公司的角度比较难于找到能去维护这种架构产品的人。需求评估当前公司是否有这个能力去维护这个产品。 zuul因为架构的原因在高并发的情况下性能不高，同时需要去基于研究整合开源的适配zuul的监控和管理系统。 orange由于没有被大量使用，同时是国内个人在开源，在可持续性和社区资源上不够丰富，出了问题后可能不容易找到人问。 另外kong提供企业版本的API网关，当然也是基于ngnix+lua的，企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。
-
5、公有云还是私有云
现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关，当然这些网关的基础功能肯定是没有问题，但是二次开发，扩展功能、监控功能可能就不能满足部分用户的定制需求了。另外很多企业因为自身信息安全的原因，不能使用外网公有网的API网关服务，这样就只有选择私有云的方案了。 在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用，无法做到定制的合作伙伴门户，这也不适合于部分企业的需求。 如果作为微服务网关，大多数情况下是希望网关服务器和服务提供方服务器是要在内网的，在这里情况下也只有私有云的API网关才能满足需求。 综合上面的分析，基础公有云的API网关只有满足一部分简单客户的需求，对于很多企业来说私有云的API网关才是正确的选择。
-
-
-
302调度
-
传统DNS调度不足
- DNS并不是为GSLB设计的
- 基于local DNS的地址判断，粒度较粗。而且LDNS可能和end user网络距离很远。
- 用户可能会设置错误的Local DNS，该服务器和用户实际距离较远，比如8.8.8.8等
- DNS请求里面不会带有内容信息，GSLB只能拥有LDNS ip信息，无法针对内容作出更加灵活的判断
-
HttpDNS
-
302调度的原理和优势
- 1.用户DNS解析域名时候，获得IP地址并不是CDN接入节点，而是CDN服务厂家调度机IP地址
- 2.用户向调度机发送请求时，会带有准确的用户端ip地址，另外由于调度机是厂家自己服务，会有足够视眼去优化调度，通过各种策略（机器负载，文件热度以及带宽冗余等），返回给用户当前最合适节点IP地址。
- 3.用户获得302响应，重新向CDN接入节点发起请求，获取响应
-
302调度的缺点
- 1.响应时间。至少会增加一次302跳转耗时
- 2.业务风险。如果调度主备集群出现异常，对全部客户业务是毁灭性的
- 3.机器成本。调度集群成本，以及各种收集监控数据，来综合判断当前调度策略。
- 4.兼容性。部分终端不支持302跳转。
-
一般是两者结合，DNS做省市级别和跨运营商的调度， 302做基于内容和精确IP的精确调度
-
-
业务模块化
（电商例：用户、商品、购物车、结算中心、价格等服务）
-
微服务
-
-
服务层
-
SOA框架（Dubbo）
- SOA：面向服务的架构(面向消息)
- 把系统按照实际业务，拆分成刚刚好大小的、合适的、独立部署的模块，每个模块之间相互独立
- dubbo.apache.org/zh-cn/docs/…
-
微服务框架（istio、Spring Cloud）
- istio：istio.io/latest/zh/d…
-
协议（RPC、RESTful）
-
RPC：远程过程调用 (面向方法)，需要客户端接口与服务端保持一致，服务端提供一个方法，客户端通过接口直接发起调用，业务开发人员仅需要关注业务方法的调用即可，不再关注网络传输的细节，在开发上更为高效。（PRC是服务端提供好方法给客户端调用。定位到类，然后通过类去调用方法。）
-
RESTful：Http接口只关注服务提供方（服务端），对于客户端怎么调用，调用方式怎样并不关心，通常情况下，客户端使用Http方式进行调用时，只要将内容进行传输即可，这样客户端在使用时，需要更关注网络方面的传输，比较不适用与业务方面的开发；（restful是服务端把方法写好，客户端通过http方式调用，直接定位到方法上面去。）
-
RPC主要是基于TCP/IP协议的，而HTTP服务主要是基于HTTP协议的，我们都知道HTTP协议是在传输层协议TCP之上的，所以效率来看的话，RPC更快
-
-
框架安全
-
应用性能监控
-
-
-
分布式层
-
消息队列
- ActiveMQ（成熟）
- RabbitMQ（成熟、案例多）
- RocketMQ（业务应用）
- ZeroMQ（快）
- Kafka（日志传输）：作为消息队列来说，企业中选择mq的还是多数，因为像Rabbit，Rocket等mq中间件都属于很成熟的产品，性能一般但可靠性较强，而kafka原本设计的初衷是日志统计分析，现在基于大数据的背景下也可以做运营数据的分析统计，而redis的主要场景是内存数据库，作为消息队列来说可靠性太差，而且速度太依赖网络IO，在服务器本机上的速度较快，且容易出现数据堆积的问题，在比较轻量的场合下能够适用
-
-
-
存储层
-
文件存储
-
单机存储
-
块存储 - 机械硬盘
块存储指在一个RAID（独立磁盘冗余阵列）集中，一个控制器加入一组磁盘驱动器，然后提供固定大小的RAID块作为LUN（逻辑单元号）的卷。
-
SSD
固态驱动器（Solid State Disk或Solid State Drive，简称SSD），俗称固态硬盘，固态硬盘是用固态电子存储芯片阵列而制成的硬盘，因为台湾英语里把固体电容称之为Solid而得名。SSD由控制单元和存储单元（FLASH芯片、DRAM芯片）组成。固态硬盘在接口的规范和定义、功能及使用方法上与普通硬盘的完全相同，在产品外形和尺寸上也完全与普通硬盘一致（新兴的U.2，M.2等形式的固态硬盘尺寸和外形和SATA机械硬盘完全不同）。
-
文件系统（ext4、xfs）
centos7.0开始默认文件系统是xfs，centos6是ext4，centos5是ext3
-
LVM
LVM 是 Logical Volume Manager 的缩写，中文一般翻译为 "逻辑卷管理"，它是 Linux 下对磁盘分区进行管理的一种机制。LVM 是建立在磁盘分区和文件系统之间的一个逻辑层，系统管理员可以利用 LVM 在不重新对磁盘分区的情况下动态的调整分区的大小。如果系统新增了一块硬盘，通过 LVM 就可以将新增的硬盘空间直接扩展到原来的磁盘分区上。
-
tmpfs
临时文件系统，是一种基于内存的文件系统，它和虚拟磁盘ramdisk比较类似像，但不完全相同，和ramdisk一样，tmpfs可以使用RAM，但它也可以使用swap分区来存储，而且传统的ramdisk是个块设备，要用mkfs来格式化它，才能真正地使用它；而tmpfs是一个文件系统，并不是块设备，只是安装它，就可以使用了。tmpfs是最好的基于RAM的文件系统。
-
-
单机存储扩展
-
文件分发（多级分发）
-
文件同步（rsync、inotify）
利用监控服务(inotify)，监控到要同步服务器的目录文件的变化 发现目录数据发生变化就利用rsync服务将数据发送到备份服务器
-
DRBD
DRBD（Distributed ReplicatedBlock Device）是一种基于软件的，无共享，分布式块设备复制的存储解决方案，在服务器之间的对块设备（硬盘，分区，逻辑卷等） 进行镜像。也就是说当某一个应用程序完成写操作后，它提交的数据不仅仅会保存在本地块设备上，DRBD也会将这份数据复制一份，通过网络传输到另一个节点的块设 备上，这样，两个节点上的块设备上的数据将会保存一致，这就是镜像功能。
-
DAS（块存储）
DAS（Direct-Attached Storage，直连附属存储)：意思是存储的设备只用于独立的一台服务器连接，很难把存储共享与其它主机（刀片应该可以实现的）存储设备是直接连接到服务器的主板总线，所以速度较快，个人认为比一般的ISCSI传输速度快的多。DAS在成本上比较低廉，性能比较稳定，但直连式存储需要依赖服务器主机的操作系统进行数据的I/O读写和存储设备管理，数据的备份和恢复，需要占用服务器主机的资源，包括CPU和系统I/O等
-
-
共享存储
-
NAS[NFS（Unix/Linux）]
NAS（Network Attached Storage，网络附属存储）：通过网络把文件服务器共享出的目录挂载到本地使用，服务器在工作中会把内存中的要存储的数据转换为网络I/O传递到文件服务器，服务器和文件服务器之间是属于文件系统I/O级别，服务器不用去关心这些数据要存放在哪些磁盘的哪些扇区，目前常见的协议有：NFS、CIFS等
-
FTP
-
SAN
SAN（Storage Area Network，存储区域网络）：通过光纤交换机或者以太网交换机把服务器和存储设备连接在一起，实现多服务器共享访问或使用一个存储阵列或集群存储。SAN中服务器和存储间是属于块级别I/O SAN分为：FC SAN 和IP SAN FC SAN需要服务器配备FC HBA卡 连接到 FC交换机，存储也通过FC HBA卡连接到FC交换机，FC的传输速度应能达到1.2GB/S 甚至更高。这种架构造价较高，但速度和稳定性较高。 IP SAN，通过以太网卡和以太网交换机，把服务器和存储之间连接起来，让服务器通过IP网络把数据存储到存储设备上，目前以有万兆网络，但尚未普及，IP SAN造价低廉，传输灵活，但速度和稳定性可能与FC SAN还要差一截
-
iSCSI
ISCSI全称是——Internet Small Computer System Interface，是一种互联网小型计算机系统接口。 一种用于计算机和智能设备之间（如：硬盘、软驱、光驱、打印机、扫描仪等）系统级接口的独立处理器标准，是一种智能的通用接口标准。 翻译成人话就是：ISCSI就是一块网络磁盘，就好像我们现在用的百度云网盘。 是一种基于客户端和服务端架构的虚拟磁盘技术，服务器提供磁盘空间，客户机连接并且可以把它当成本地磁盘来用
-
-
分布式存储
-
原理
-
集中式存储基本架构
集中式存储最大的特点是有一个统一的入口，所有数据都要经过这个入口，这个入口就是存储系统的机头。
-
中间控制节点架构（HDFS）
在该系统的整个架构中将服务器分为两种类型，一种名为namenode，这种类型的节点负责管理管理数据（元数据），另外一种名为datanode，这种类型的服务器负责实际数据的管理。
-
完全无中心架构---计算模式（Ceph）
如图是Ceph存储系统的架构，在该架构中与HDFS不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系计算出来其写入数据的位置，这样客户端可以直接与存储节点通信，从而避免中心节点的性能瓶颈。
-
完全无中心架构---一致性哈希（Swift）
一致性哈希的方式就是将设备做成一个哈希环，然后根据数据名称计算出的哈希值映射到哈希环的某个位置，从而实现数据的定位。 在Swift对象存储中，通过账户名/容器名/对象名三个名称组成一个位置的标识，通过该唯一标识可以计算出一个整型数来。这样，Swift就可以将请求重新定向到该设备进行处理。
-
-
方案
- GlusterFS
- MooseFS
- Ceph
- FastDFS（非对象存储）
-
-
-
DAL
-
概念
dal是数据访问层的英文缩写，即为数据访问层（Data Access Layer）。其功能主要是负责数据库的访问。简单地说就是实现对数据表的Select（查询）、Insert（插入）、Update（更新）、Delete（删除）等操作
-
应用层分片
垂直拆分、读写分离、分库分表(水平拆分) zhuanlan.zhihu.com/p/87144535
-
淘宝TDDL
-
开源：360（Atlas）阿里（Cobar）、MyCat、MySQL-Proxy、根据业务开发
-
-
数据存储
-
分布式缓存
- Memcached、Redis（客户端分片、Redis Cluster、Twemproxy、Codis）
-
NoSQL
- Redis、LevelDB（SSDB）、CouchDB、Mongodb、Couchbase 、Cassandra、TiDB（支持MySQL协议）
-
时间序列
- RRDTool、Graphite Whisper、OpenTSDB、InfluxDB、KairosDB、ElasticSearch、Hbase
-
RDBMS
- MySQL（PXC集群、MHA）、Oracle（DG、OGG、RAC）、PostgreSQL、SqlServer、SQLite、DB2
-
大数据
-
Hadoop生态圈（HDFS、Hive、Hbase、Zookeeper、Pig、Spark、Impala、Kudu）、Mahout智能推荐
-
Zookeeper
-
-
-
-
-
基础服务层
-
业务决策
- 灰度发布
- 服务降级
- 异地灾备
- 数据分析平台
- 智能扩容决策树（需要各层支持）
- 智能监控
-
运维相关
- 项目管理（Redmine、Jira、知识库、Bugzilla、CodeReview）、工单系统、运维操作平台、监控平台
-
应用相关
- 持续集成、日志收集平台（ELKStack即Elasticsearch、Logstash 和 Kibana）、自动化部署平台、Job管理（调度）平台、安全扫描平台
-
系统相关
-
LDAP
统一身份认证主要是改变原有的认证策略，使需要认证的软件都通过LDAP进行认证，在统一身份认证之后，用户的所有信息都存储在AD Server中。终端用户在需要使用公司内部服务的时候，都需要通过AD服务器的认证
-
内部DNS
-
DHCP
DHCP是Dynamic Host Configuration Protocol的缩写，即动态主机配置协议。DHCP是一个很重要的局域网的网络协议，使用UDP协议工作，主要有以下用途： 1、为内部网络或网络服务供应商自动分配IP地址； 2、为用户或者内部网络管理员作为对所有计算机作中央管理的手段； 3、为内部网络用户接受IP租约。
-
Mail、SMS、Gitlab、Yum仓库、操作审计（xenapp）、堡垒机
-
-
-
容器层
-
容器
Linux 容器技术能够对应用及其整个运行时环境（包括全部所需文件）一起进行打包或隔离。从而可以在不同环境（如开发、测试和生产等环境）之间轻松迁移应用，同时还可保留应用的全部功能。容器也是保障IT 安全的一个重要组成部分。将安全性内置于容器管道，可以为基础架构增添防护，从而保障容器的可靠性、可扩展性和信赖度。
-
容器与虚拟化
虚拟化技术通过Hypervisor实现VM与底层硬件的解耦。而容器（container）技术是一种更加轻量级的操作系统虚拟化技术，将应用程序及其运行依赖环境打包封装到标准化、强移植的镜像中，通过容器引擎提供进程隔离、资源可限制的运行环境，实现应用与OS平台及底层硬件的解耦，一次打包，随处运行。容器基于镜像运行，可部署在物理机或虚拟机上，通过容器引擎与容器编排调度平台实现容器化应用的生命周期管理 VM中包含GuestOS，调度与资源占用都比较重。而容器仅包含应用运行所需的文件，管理容器就是管理应用本身。如上表，容器具有极其轻量、秒级部署、易于移植、敏捷弹性伸缩等优势；但VM是OS系统级隔离，而容器是进程级隔离，容器的安全性相对更弱一些，需要一些额外的安全技术或安全容器方案来弥补。作为云原生的核心技术，容器、微服务与DevOps/ CICD）等技术已成为应用架构转型或实现技术中台不可或缺组件。
-
容器应用架构
-
-
容器编排
容器编排是指自动化容器的部署、管理、扩展和联网。容器编排可以为需要部署和管理成百上千个 Linux® 容器和主机的企业提供便利。 容器编排可以在使用容器的任何环境中使用。它可以帮助您在不同环境中部署相同的应用，而无需重新设计。通过将微服务放入容器，就能更加轻松地编排各种服务（包括存储、网络和安全防护）。 容器可为基于微服务的应用提供理想的应用部署单元和独立的执行环境。借助容器，您不仅能以微服务的方式在同一硬件上单独运行一个应用的多个部分，还能更好地控制每个部分及其生命周期。 使用容器编排可以自动化和管理任务，例如： 置备和部署 配置和调度 资源分配 容器可用性 根据平衡基础架构中的工作负载而扩展或删除容器 负载平衡和流量路由 监控容器的健康状况 根据运行应用的容器来配置应用 保持容器间交互的安全
- Mesos（Marathon、Chronos）、Kubernetes、Docker Swarm、Rancher、CoreOS（fleet）、OpenStack（Magnum）
-
容器和系统
- 容器：LXC、LXD、Docker、rkt
- 系统：CoreOS、Atomic、RancherOS
-
网络和存储
- 网络：Calico、Flanel、Weave Net
- 存储：Ceph 镜像管理：Docker Registry、Harbor
-
-
操作系统层
-
CPU
- CPU运行级别、使用率、上下文切换、运行队列、进程调度、系统调用、CPU管理（进程管理、taskset、intel VT-X）
-
内存
- 虚拟内存、SWAP换入换出、内存寻址、内存管理（Buffer Cache、HugePages、ksmd、EPT）
-
I/O（磁盘）
- 缺页中断、IOPS（顺序IO、随机IO）、IO管理（IO调度算法、virtio）、VFS
-
I/O（网络）
- TCP/IP（三次握手、四次挥手、状态转换、TCP队列）、IO模型、Bonding、Bridge、网络管理（iftop、tcpdump）
-
内核/Shell
- 内核定制、内存参数优化、脚本编程（AWK、Sed、Shell、Python、PHP、Perl、Ruby、Lua）
-
-
基础设施层
-
IAAS(基础设施即服务)
- 公有云、私有云（OpenStack/cloudstack+KVM/XEN、oVirt）、混合云
-
硬件管理
- 硬件选型、配件更换、资产录入、系统安装（Cobbler）、标签化、Raid构建、远程控制（KVM、iDrac、ILO、IMM）
-
IDC托管
- 需求分析、IDC选型、网络测试、谈价格、签合同、设备采购（原厂vs渠道）、机柜和机位规划
-
数据中心
- 数据中心选址、制冷、供电、网络、运维
-
-
其他
-
运维产品化
-
基于DevOps产品思路
- 项目管理（类似Jira）、Bug管理、代码托管（类似Gitlab）、持续交付（类似Jenkins的构建、测试、部署）
-
自动化运维产品思路
- CMDB、ITSM管理系统（事件管理、问题管理、故障管理、工单系统）、作业平台、堡垒机、APM、私有云平台
-
-
运维服务化
- OAAS ：Operations as a Service,运维咨询、运维托管、技术培训、应急处理、产品即服务、DevOps专家服务
-
测试和开发相关
- 运维协助：性能测试（TCPCopy、日志转换）、单机监控（nmon）、环境规划（开发、测试、预生产、生产）、CI（持续集成）、自动化部署
-
运维管理体系
- 运维管理必会：ITSM、ITIL V3、IT Service CMM、Six Sigma、DevOps Master、项目管理（PMBok）、架构层面（知识体系、运维方案、容量规划、灾备规划、服务降级）
-
运维发展趋势（个人理解）
- 打杂（小公司啥都干）->分层（应用运维、系统运维、基础运维、运维开发等）->场景化（分业务）->自动化（最终大家的目标都是自动化）
-
运维自动化发展趋势（个人理解）
- 标准化（文档化、流程化）->工具化（流程固化为工具）->Web化（平台化）->服务化（API化）->智能化（自动化）->产品化（服务化，云服务、运维创业）
-
