容灾

（一）网络操作系统安全 网络操作系统安全是整个网络系统安全的基础。操作系统安全机制主要包括 访问控制 和 隔离控制 。 访问控制系统一般包括主体、客体和安全访问政策 访问控制类型： 自主访问控制 强制访问控制 访问控制措施： 入网访问控制 权限访问控制 属性访问控制 身份验证 网络端口和结点的安全控制 （二）网络实体安全 计算机网络实体是网络系统的核心，既是对数据进行加工处理的中心，也是信息传输的控制中心 网络设备的冗余 网络服务器系统冗余： 双机热备份：设置两台服务器（一个主服务器，一个备份服务器） 存储备份冗余 磁盘镜像 RAID 电源冗余：采用双电源系统（即服务器电源冗余） 网卡冗余 核心交换机冗余 供电系统冗余：使用UPS作为备份电源 链接冗余 网络边界设置冗余 ACL(路由器访问控制列表) 基于包过滤的流控制技术，主要作用一方面保护网络资源，阻止非法用户对资源的访问，另一方面限制特定用户所能具备的访问权限 类型： 标准ACL：序列号1-99 扩展ACL：序列号100-199 VRRP(虚拟路由器冗余协议) 选择性协议，可把一个虚拟路由器的责任动态分配到局域网上VRRP路由器 交换机端口汇聚 端口聚合也称以太通道，主要用于交换机之间的连接。就是将多个物理端口合并成一个逻辑端口 Internet上的应用服务器 HDCP服务器 Web服务器 FTP服务器 DNS服务器

当今世界，互联网、大数据应用迅猛发展，物联网、人工智能、云计算 技术日新月异，随之而来的是各种企业和个人应用持续不断地产生亿级甚至是百亿级的海量小文件。这些小文件的元数据管理、存储性能以及访问效率等问题因而成为学术界和工业界公认的难题。 例如，国内目前最大的电商网站淘宝存储的商品图片超过 200 亿张，这些文件的平均大小仅为 15KB 左右，国外著名的社交网站Facebook 存储的图片总量更是超过了600亿张；在线视频播放服务中，每个视频会被切片服务器分割成 1MB 左右的分片文件，一部动画电影所包含的图片文件可能会超过 500 万张，平均大小为15KB；一些在线阅读图书每页内容均会被扫描成大约几十KB的图片文件…… 在非结构化数据和新应用快速增加的情况下，对象存储更能满足企业的业务需求。为此，杉岩数据推出了强大的对象存储产品，解决企业对海量图片、视频等非结构数据存储需求，以便更好的挖掘非结构化数据的价值。 端到端的Scale-Out扩展，实现大数据积累 分布式对象存储总容量可达到数百PB级规模，单个名字空间也可以扩展到整个硬件存储总空间容量，不需要割裂成多个隔离空间，并且在文件数量上会有更大的扩展，文件数量可达百亿级，是真正的端到端Scale-Out快速扩展。它可以满足业务系统整个生命周期的存储容量需求，无需挂载目录和调整业务系统，让IT人员更加关注业务价值本身。

分布式存储往往采用分布式的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息。它不但提高了系统的可靠性、可用性和存取效率，还易于扩展，将通用硬件引入的不稳定因素降到最低。优点如下： 分布式存储的六大优点 1. 高性能 一个具有高性能的分布式存户通常能够高效地管理读缓存和写缓存，并且支持自动的分级存储。分布式存储通过将热点区域内数据映射到高速存储中，来提高系统响应速度;一旦这些区域不再是热点，那么存储系统会将它们移出高速存储。而写缓存技术则可使配合高速存储来明显改变整体存储的性能，按照一定的策略，先将数据写入高速存储，再在适当的时间进行同步落盘。 2. 支持分级存储 由于通过网络进行松耦合链接，分布式存储允许高速存储和低速存储分开部署，或者任意比例混布。在不可预测的业务环境或者敏捷应用情况下，分层存储的优势可以发挥到最佳。解决了目前缓存分层存储最大的问题是当性能池读不命中后，从冷池提取数据的粒度太大，导致延迟高，从而给造成整体的性能的抖动的问题。 3. 多副本的一致性 与传统的存储架构使用RAID模式来保证数据的可靠性不同，分布式存储采用了多副本备份机制。在存储数据之前，分布式存储对数据进行了分片，分片后的数据按照一定的规则保存在集群节点上。为了保证多个数据副本之间的一致性，分布式存储通常采用的是一个副本写入，多个副本读取的强一致性技术，使用镜像、条带

容灾恢复是绝大多数企业级应用的基本要求 在没有Kubernetes也没有容器的时候，备份和恢复解决方案通常在虚拟机（VM）级别上实现。当应用程序在单个VM上运行时，容灾系统适用于这样的传统应用程序。但是，当使用Kubernetes对应用程序进行容器化管理时，这样的容灾系统就无法使用了。有效的Kubernetes容灾恢复方案必须针对容器化架构进行重新设计，并按Kubernetes的原生方式来运行。 传统的基于VM的备份和恢复解决方案，使用快照来收集数据，但这些数据对于某个具体容器化应用并不足够。因为任何一个特定的VM都将包含来自多个应用的数据。如果您尝试通过VM快照来备份APP 1，将会同时获取其他应用的多余数据。但这些数据从容器角度来看又不够：APP 1可能还会将数据存储在其他VM上。因此通过对某个单独VM的快照无法捕获所有APP1的数据。 基于分布式体系结构的现代应用需要的容灾方案，需要能够找到特定应用的所有相关数据和配置信息，并能够以零RPO（Recovery Point Objective，复原点目标）和接近零RTO（Recovery Time Object，复原时间目标）的方式进行恢复。 一个有效的Kubernetes容灾解决方案需要具备： 容器粒度的控制 能够备份数据和配置 Kubernetes命名空间感知 针对多云和混合云架构的优化 保持应用的一致性

容灾恢复是绝大多数企业级应用的基本要求 在没有Kubernetes也没有容器的时候，备份和恢复解决方案通常在虚拟机（VM）级别上实现。当应用程序在单个VM上运行时，容灾系统适用于这样的传统应用程序。但是，当使用Kubernetes对应用程序进行容器化管理时，这样的容灾系统就无法使用了。有效的Kubernetes容灾恢复方案必须针对容器化架构进行重新设计，并按Kubernetes的原生方式来运行。 传统的基于VM的备份和恢复解决方案，使用快照来收集数据，但这些数据对于某个具体容器化应用并不足够。因为任何一个特定的VM都将包含来自多个应用的数据。如果您尝试通过VM快照来备份APP 1，将会同时获取其他应用的多余数据。但这些数据从容器角度来看又不够：APP 1可能还会将数据存储在其他VM上。因此通过对某个单独VM的快照无法捕获所有APP1的数据。 基于分布式体系结构的现代应用需要的容灾方案，需要能够找到特定应用的所有相关数据和配置信息，并能够以零RPO（Recovery Point Objective，复原点目标）和接近零RTO（Recovery Time Object，复原时间目标）的方式进行恢复。 一个有效的Kubernetes容灾解决方案需要具备： 容器粒度的控制 能够备份数据和配置 Kubernetes命名空间感知 针对多云和混合云架构的优化 保持应用的一致性

最近11月份有点忙，没有更新博客。见谅！ 又快接近年底了，正好今天有空，想写一下一个合格的架构师需要知道哪些东西。下面我整理了一下，重看一边： 1.计算机的基础知识整理一遍。（最好包括硬件和软件基础知识再理一边，所谓温故而知新） 比如进制转换，局域网，城域网，广域网，物数网传会表应 7层协议 。多媒体应用基础。还有简单一些算法知识点。 2.所有JAVA知识整理一遍。 可以先过一边JAVA SE ，逻辑思想，这个很快。然后简单看一下spring 框架等。 3.扩展知识点整理一遍。 比如skywalking,docker,k8s,MapReduce,ELK 等一些常用的扩展插件。 围绕这三点重新看一下，肯定收获不小，下面我整理一下需要用的一些技术点： 数据结构队列 集合 链表、数组 字典、关联数组 栈 树二叉树 完全二叉树 平衡二叉树 二叉查找树（BST） 红黑树 B，B+，B*树 LSM 树 BitSet 常用算法排序、查找算法选择排序 冒泡排序 插入排序 快速排序 归并排序 希尔排序 堆排序 计数排序 桶排序 基数排序 二分查找 Java 中的排序工具 布隆过滤器 字符串比较KMP 算法 深度优先、广度优先 贪心算法 回溯算法 剪枝算法 动态规划 朴素贝叶斯 推荐算法 最小生成树算法 最短路径算法 并发Java 并发 多线程 线程安全 一致性、事务事务 ACID 特性

摘自： https://www.cnblogs.com/mayou18/p/9829876.html 聊聊微服务的服务注册与发现 来源：阿里中间件团队分享 更多文章请关注 MAYOU18 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 引言 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 在这之前，站在组件使用者的角度，我想先问这么几个问题： 注册的 IP 和端口怎么确定 ？ 实现服务治理还需要注册哪些信息 ？ 如何进行优雅的服务注册与服务下线 ？ 注册服务的健康检查是如何做的 ？ 当服务有节点退出或新的节点加入时，订阅者能不能及时收到通知 ? 我能方便地查看某个应用发布和订阅了哪些服务，以及所订阅的服务有哪些节点吗 ？ 看完这些问题后，您也许会发现，对于服务注册与发现，首先应该关注的是服务注册发现本身的功能，然后才是性能和高可用。 一个好的服务注册发现中间件，应该是能完整地满足服务开发和治理的基础功能，然后才是性能和高可用。如果没有想清楚前面的功能，再高的可用性和性能都是浮云。最后，安全也同样重要。 服务端的性能如何 ？

基础: 磁盘镜像技术DRBD DRBD( Distributed Replicated Block Device )是由内核模块和相关脚本构成，用以构建高可用性的集群。其实现方式是通过网络来镜像整个设备。它允许用户在远程机器上建立一个本地块设备的实时镜像。也可以把它看成一个网络RAID1. 工作原理： DRBD负责接收数据，把数据写到本地磁盘，然后发送给另一个主机。另一个主机再将数据存到自己的磁盘中。目前，DRBD每次只允许对一个节点进行读写访问，这对于通常的故障切换高可用性集群已经够了。 DRBD协议： A：数据一旦写入磁盘并发送到网络中就认为完成了写入操作 B：收到接受确认就认为完成了写入操作 C：收到写入确认就完成了写入操作 目前运用最多的就是C协议 DRBD的三个进程： drbd0——worker：主进程 drbd0——asender：primary上drbd0的数据发送进程 drbd0——receiver；secondary上drbd0的数据接受进程 配置DRBD前需要注意几点： mount drbd设备以前必须把设备切换到primary状态 两个节点中，同一时刻只能有一台处于primary状态，另一台处于secondary状态，处于secondary状态的服务器上不能加载drbd设备。主备服务器同步的两个分区大小最好相同，这样不至于浪费磁盘空间

聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 引言 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 在这之前，站在组件使用者的角度，我想先问这么几个问题： 注册的 IP 和端口怎么确定 ？ 实现服务治理还需要注册哪些信息 ？ 如何进行优雅的服务注册与服务下线 ？ 注册服务的健康检查是如何做的 ？ 当服务有节点退出或新的节点加入时，订阅者能不能及时收到通知 ? 我能方便地查看某个应用发布和订阅了哪些服务，以及所订阅的服务有哪些节点吗 ？ 看完这些问题后，您也许会发现，对于服务注册与发现，首先应该关注的是服务注册发现本身的功能，然后才是性能和高可用。 一个好的服务注册发现中间件，应该是能完整地满足服务开发和治理的基础功能，然后才是性能和高可用。如果没有想清楚前面的功能，再高的可用性和性能都是浮云。最后，安全也同样重要。 服务端的性能如何 ？ 服务发现的容灾策略是怎样的 ？ 当我的应用和服务发现中心的网络连接出现问题时，会对我的调用产生什么影响 ？ 服务注册中心某台机器宕机或者全部宕机时，会对我的调用产生什么影响 ？

最新后端架构师技术图谱 深呼吸，慢慢学 ，技术长路漫漫… 数据结构 二叉树 完全二叉树 平衡二叉树 二叉查找树（BST） 红黑树 B-，B+，B*树 LSM 树 队列 集合 链表、数组 字典、关联数组 树 BitSet 常用算法 KPM 算法 选择排序 冒泡排序 插入排序 快速排序 归并排序 希尔排序 堆排序 计数排序 桶排序 基数排序 二分查找 Java 中的排序工具 排序、查找算法 布隆过滤器 字符串比较 深度优先、广度优先 贪心算法 回溯算法 剪枝算法 动态规划 朴素贝叶斯 推荐算法 最小生成树算法 最短路径算法 并发 Java中的锁和同步类 公平锁 & 非公平锁 悲观锁 & 乐观锁 & CAS ABA 问题 CopyOnWrite容器 RingBuffer 可重入锁 & 不可重入锁 互斥锁 & 共享锁 死锁 事务 ACID 特性 事务的隔离级别 多线程 线程安全 一致性、事务 锁 操作系统 计算机原理 进程 线程 协程 Linux 设计模式 康威定律 设计模式的六大原则 23种常见设计模式 应用场景 单例模式 责任链模式 MVC IOC AOP UML 微服务思想 运维 & 统计 & 技术支持 OpenStack Docker KVM Xen OpenVZ TDD 理论 单元测试 压力测试 全链路压测 A/B Test Ansible puppet chef Jenkins