网络架构

这个章节主要讲Active Directory 域服务概述及相关概念，设计步骤及AD常见的规划设计TOP方案，每种架构TOP方案的特定及优缺点。 一 、Active Directory 域服务概述 Active Directory是存储有关网络上对象的信息的层次结构。 目录服务（例如 Active Directory 域服务（AD DS））提供存储目录数据以及使此数据可供网络用户和管理员使用的方法。 例如，AD DS 存储有关用户帐户的信息，如名称、密码、电话号码等，并使同一网络上的其他授权用户可以访问此信息。 Active Directory 存储有关网络上对象的信息，并使管理员和用户可以轻松查找和使用此信息。 Active Directory 使用结构化数据存储作为目录信息的逻辑层次结构的基础。 此数据存储（也称为目录）包含 Active Directory 对象的相关信息。 这些对象通常包含共享资源，如服务器、卷、打印机、网络用户和计算机帐户。 通过登录身份验证和对目录中对象的访问控制，安全与 Active Directory 集成。 通过单一网络登录，管理员可以管理其整个网络中的目录数据和组织，授权网络用户可以访问网络上任何位置的资源。 基于策略的管理简化了复杂的网络的管理。 Active Directory 包括 一组规则，即架构，定义目录中包含的对象和属性的类别

作者 | 王夕宁 阿里巴巴高级技术专家 关注“阿里巴巴云原生”公众号，参与文末留言互动，即有机会获得赠书福利！ 本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书，文章从基础概念入手，介绍了什么是服务网格及 Istio，针对 2020 服务网格的三大发展趋势，体系化、全方位地介绍了 Istio 服务网格的相关知识。 你只需开心参与公众号文末互动，我们负责买单！技术人必备书籍《Istio 服务网格技术解析与实践》免费领~ 有 外文 指出，2020 年 Service Mesh 技术将有以下三大发展： 快速增长的服务网格需求； Istio 很难被打败，很可能成为服务网格技术的事实标准； 出现更多的服务网格用例，WebAssembly 将带来新的可能。 什么是服务网格 Gartner 2018 关于服务网格技术趋势分析报告，展示了一系列的服务网格技术，划分服务网格技术的依据是基于应用服务代码是否必须对其服务网格感知及其是否锁定，或锁定的程度。 基于编程框架的网格技术可以帮助开发人员构建一个架构体系良好的服务，但这会导致应用代码与框架和运行时环境的紧密耦合。而基于 Sidecar 代理的服务网格技术不会为开发人员设置这些障碍，并且使其管理和维护更加轻松，能够提供更灵活的方法来配置运行时策略。 在微服务环境中，可将单一应用程序分解为独立的多个组件

声明 本文转自 https://developer.51cto.com/art/201906/597963.htm 什么是RPC 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 等。 常用的RPC框架 gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的

点点这个链接免费获取： 【推荐】2020年最新Java电子书集合.pdf(吐血整理) >>> 背景 作为一个重要业务，微信支付在客户端上面临着各种问题。其中最核心问题就是分平台实现导致的问题： iOS 和安卓实现不一致 容易出 Bug 通过沟通保证不了质量 扩展性差，无法快速响应业务需求 需求变更迭代周期长 数据上报不全面 质量保障体系不完善 缺少业务及设计知识沉淀 协议管理松散 缺少统一的自动化测试 用户体验不一致比如下图就是之前安卓和 iOS 没有统一前的收银台。 为了解决分平台实现这个核心问题，并解决以往的技术债务。我们建立起了一整套基于 C++ 的跨平台框架，并对核心支付流程进行了重构。 微信支付跨平台从 iOS 7.0.4 版本起， 安卓从 7.0.7 版本起全面覆盖。 线上效果指标 以 iOS 上线情况为例: Crash 率上线前后 Crash 率保持平稳，没有影响微信稳定性，跨平台支付无必现 Crash，做到了用户无感知切换。举个例子，大家可以用微信发一笔红包，拉起的收银台和支付流程就是由基于C++编写的跨平台代码所驱动的。 效能提升以核心支付流程代码为例，跨平台需要 3512 行，iOS 原生需要 6328 行。减少了近 45% 的代码。以新需求开发为例：7.0.4 版本需求一：收银台改版7.0.4 版本需求二：简化版本收银台 跨平台实现：iOS + 安卓 共计 3

背景 某集团经过多年的经营，公司业务和规模在不断发展，公司管理层和IT部门也认识到通过信息化手段可以更好地支撑公司业务运营、提高企业生产和管理效率。同时随着新建办公大楼、研发大楼和厂房的落成，IT部门也需要对整个集团的信息化和企业IT基础架构进行规划和建设。目前主要分为以下两部分： 楼宇智能化规划和建设方案：主要包括视频监控、门禁系统、语音和数据节点规划和布线、CATV、大屏幕电子显示屏、机房建设等。 企业IT基础架构规划和解决方案：主要包括企业局域网基础网络拓扑规划和网络设备选型、互联网接入和VPN接入、IT硬件部署和选型、企业IT信息化基础软件系统规划和选型等。 本方案主要是针对某集团企业IT基础架构进行规划，并提出解决方案和进行投资预算。而关于楼宇智能化规划和建设的方案参见其它相关方案。 企业IT架构 一般企业的IT架构情况，本方案主要针对IT基础架构部分进行规划，并提供选型和部署参考，关于企业IT业务应用系统部分的规划和建设请参考其它方案。 网络系统规划 当前，企业一般能给信息化方面投入有限。除了人力有限，还缺少专业人才，应用能力、维护能力、开发能力、实施能力等都普遍较弱，这就要求网络架构成熟、稳定安全、高可靠、高可用，尽可能少投入人力和金钱进行维护。其次，由于企业首要解决的是生存问题，根本没办法做到“先信息化，再做业务”，因此网络建设实施要求必须容易，实施时间必须极短。

点点这个链接免费获取：本人免费整理了Java高级资料，涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程，一共30G，需要自己领取。 传送门： https://mp.weixin.qq.com/s/osB-BOl6W-ZLTSttTkqMPQ 背景 作为一个重要业务，微信支付在客户端上面临着各种问题。其中最核心问题就是分平台实现导致的问题： iOS 和安卓实现不一致 容易出 Bug 通过沟通保证不了质量 扩展性差，无法快速响应业务需求 需求变更迭代周期长 数据上报不全面 质量保障体系不完善 缺少业务及设计知识沉淀 协议管理松散 缺少统一的自动化测试 用户体验不一致比如下图就是之前安卓和 iOS 没有统一前的收银台。 为了解决分平台实现这个核心问题，并解决以往的技术债务。我们建立起了一整套基于 C++ 的跨平台框架，并对核心支付流程进行了重构。 微信支付跨平台从 iOS 7.0.4 版本起， 安卓从 7.0.7 版本起全面覆盖。 线上效果指标 以 iOS 上线情况为例: Crash 率上线前后 Crash 率保持平稳，没有影响微信稳定性，跨平台支付无必现 Crash，做到了用户无感知切换。举个例子，大家可以用微信发一笔红包，拉起的收银台和支付流程就是由基于C++编写的跨平台代码所驱动的。

声明 本文转自https://developer.51cto.com/art/201906/597963.htm 什么是RPC 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 等。 常用的RPC框架 gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的

3 月，跳不动了？>>> 本文原文由微信客户端高级工程师方秋枋原创发表于WeMobileDev公众号，收录时有修订和加工，感谢作者的无私分享。 1、引言 作为一个重要业务，微信支付在客户端上面临着各种问题。 其中最核心问题就是分平台实现导致的问题： 1）iOS 和安卓实现不一致：容易出 Bug、通过沟通保证不了质量； 2）扩展性差且无法快速响应业务需求：需求变更迭代周期长、数据上报不全面； 3）质量保障体系不完善：缺少业务及设计知识沉淀、协议管理松散、缺少统一的自动化测试； 4）用户体验不一致：比如下图就是之前安卓和 iOS 没有统一前的收银台。 ▲ 微信安卓片和iOS版，没有统一用户体验前的收银台功能 为了解决分平台实现这个核心问题，并解决以往的技术债务。我们建立起了一整套基于 C++ 的跨平台框架，并对核心支付流程进行了重构。微信支付跨平台从 iOS 7.0.4 版本起， 安卓从 7.0.7 版本起全面覆盖。 重构后的软件架构原理如下图所示： 本文分享了微信团队基于 C++ 的移动端跨平台技术在重构整个微信支付功能的过程中，对于移动端软件架构设计方面的思考和实践总结。 术语约定： 本文中的名词 CGI 可以理解为一个网络请求，类似HTTP请求。 2、关于作者 方秋枋： 毕业于华中科技大学，现为微信客户端高级工程师。目前主要负责微信支付的跨平台开发框架与相关业务开发。 是开源项目

OpenStack入门之核心组件梳理（5）——Neutron篇 前言 ​ 本文将讲解OpenStack核心组件之一的Neutron组件。希望阅读本文前，建议初学者提前认知云计算、Linux操作系统、服务器群集以及OpenStack概念以及架构图。本文主要是为了自行整理有关OpenStack的相关知识理论，也是同读者分享自己对OpenStack中Neutron下面的浅解。 ​ 友情链接：下面的三篇文章对于初学者或多或少可以帮你在宏观上了解云计算以及OpenStack。 ​ 云计算浅谈 ​ OpenStack概念以及核心组件概述 ​ OpenStack部署节点类型和架构 一、Neutron的基本概念 1.1Neutron的前世今生 ​ Neutron的前身是Quantum，Quantum英文为量子，Neutron英文翻译为中子，虽然笔者不知道这样来命名项目的具体原因，但从直观的感觉上就会觉得这个玩意不简单哈！ ​ 其实最初OpenStack并没有将网络组件独立出来，为之成立单独的一个核心项目，最初是一个叫做Nova-network的网络模型，这种模型非常简单，就是一种单一的平面网络，如下图所示： ​ 但若熟悉网络知识就会发这种模式存在很大的缺点，比如： 单一网络有瓶颈，没有体现出云的特性（如可伸缩）； 难以实现租户的隔离性； ​ 所以技术需要不断更新发展，相关的技术大佬经过思索，尝试

三、OVN入门 3.1 OVN简介 Open vSwitch（OVS）是一款开源的“虚拟交换机”，控制协议方面它不但支持OpenFlow的所有特性而且扩展了部分OpenFlow的功能；Overlay协议方面它支持GRE, VXLAN, STT, Geneve四种主流Overlay数据包。OVS已经是 数据平面 的事实标准了，很多白盒交换机都兼容它提供的接口；还有一些x86架构的交换机则直接是基于OVS和DPDK的。所以无论“上层”的ODL、ONOS、Neutron如何的翻天覆地的“闹腾”而OVS还是岿然不动（最后流表的执行者还是OVS）。 但是长期一来OVS都缺乏一个统一的网络模型（Neutron虽然花费巨大力气实现一个网络模型但是仅仅适用于OpenStack而无法用于容器更加无法单独使用），于是在2015年OVS社区宣布了一个子项目——Open Virtual Network（OVN）。它旨在为OVS提供一个控制平面，通过一个统一的网络模型为容器、虚拟机提供相同的网络服务。 虽然很多人不愿意承认但是事实上它瞄准的对象是三个——ODL、ONOS、Neutron。我们可以看一下OpenStack中networking-ovn子项目，它是基于OVN实现的“Neutron”旨在替换Neutron的L2、L3功能。对比传统的Neutron的L2、L3的实现代码它的代码量非常少