お前はどこまで見えている

1. BBP（贝利-波尔温-普劳夫）公式 π=∑k=0∞116k(48k+1−28k+4−18k+5−18k+6)\begin{array}{c} \pi = \sum_{k=0}^\infty{1 \over 16^k}({4 \over {8k + 1}} - {2 \over {8k + 4}} - {1 \over {8k + 5}} - {1 \over {8k + 6}}) \end{array} π=∑k=0∞​16k1​(8k+14​−8k+42​−8k+51​−8k+61​)​ 该公式给出了一个求 π{\pi}π 在十六进制下小数点后第 n+1{n+1}n+1 位数值位的算法，实现步骤如下： 对公式中的每一项进行拆分，拆成 nnn 之前和 nnn 之后两部分。 以公式中第一项为例： ∑k=0∞116k(8k+1)=∑k=0n116k(8k+1)+∑k=n+1∞116k(8k+1)\begin{array}{c} \sum_{k=0}^\infty{1 \over {16^k(8k + 1)}} = \sum_{k=0}^n{1 \over {16^k(8k + 1 ...

1. 简介 CDN（内容分发网络）是指一种透过互联网互相连接的电脑网络系统，其利用最靠近用户的服务器，为每位用户提供高性能、可扩展性及低成本的网络内容传递。 现在大部分大网站都是利用 CDN 技术来实现数据的分发，比如 Github 等网站。 2. 组成 CDN 网络包含的功能实体主要有： 内容缓存设备：用户接入点，实现内容的边缘传播和存储。 内容交换机：连接用户接入点的中心，对内容进行缓存负载平衡及访问控制。 内容路由器：通过负载均衡系统实现，动态均衡各个内容缓存站点的载荷分配，为用户请求选择最佳访问站点。 内容管理系统：负责整个CDN的内容管理（内容的发布、分发、审核等）。 3. 原理 CDN 网络节点会在多个地点、多个不同的网络上进行部署，这些节点之间会动态的互相传输内容。在用户访问网站时，利用全局负载技术指定距离用户最近的服务器直接相应用户请求。 4. 作用 增大网络系统的承载量 降低供应商的带宽成本 提高用户的下载速度 异地备援提高网络稳定性 5. 关键技术 内容发布：借助于建立索引、缓存、流分裂、组播等技术，将内容发布到距离用户最近的远程服务点。 内容路由：通过 ...

1. 简介 由于网络中存在 DNS 污染和 DNS 劫持的问题，因此有时我们需要更改自己主机上默认的 DNS 服务器地址。 2. Linux 更改 DNS 地址 临时修改 DNS 地址（重启电脑后失效） 直接在 /etc/resolv.conf 文件中修改 DNS 地址，格式为 nameserver x.x.x.x 1sudo vim /etc/resolv.conf 永久修改 DNS 地址 Linux 系统可能没有默认安装 resolvconf 软件，此时需要手动安装 1sudo apt install resolvconf 安装完后重启系统该软件才会生效。 然后使用如下命令： 1sudo vim /etc/resolvconf/resolv.conf.d/base 在打开的文件中，添加/修改 DNS 地址，格式同样为 nameserver x.x.x.x 接着使用如下命令刷新系统 DNS 地址： 1sudo resolvconf -u 判断系统 DNS 地址是否已更新，可以通过查看此种更改前后 /etc/resolv.conf 文件内容： 1cat /etc/resolv. ...

1. DNS 污染 DNS 污染又称 DNS 缓存投毒，通过制造一些虚假的域名服务器数据包，将域名指向不正确的 IP 地址。 工作原理 由于域名查询没有任何认证机制，且通常是基于无连接不可靠的 UDP 协议，查询者只接受最先到达且格式正确的查询结果（后来的查询结果均被丢弃），因此可以通过对 UDP 的53端口上的域名查询进行 IDS 入侵检测，一旦发现相匹配的域名查询请求，就立刻伪装成目标域名的解析服务器返回虚假的查询结果。 不过由于缓存过期时间的限制，污染的域名不是一成不变的，若某个污染过的域名缓存记录过了缓存过期时间后没有对其进行再污染，则该域名的污染就会消失。 解决办法 绕过被污染的非权威 DNS 服务器，直接访问干净的公共 DNS 服务器。 在本机直接绑定 hosts，绕过 DNS 解析过程。（但由于 IP 地址会变更，故本机的 hosts 也需要不断更新） 对于无法绕开的 DNS 服务器，需要使用混淆/加密代理让它无法识别、篡改 DNS 数据。（该方法也可以绕过 IP 黑名单机制） 2. DNS 劫持 DNS 劫持指 DNS 服务器被控制，用户查询 DNS 时， ...

1. 服务发布和查询 1.1 概念 SOAP、WSDL、XML Schema 已经可以完成点到点的调用，但点到点的调用不能完全发挥面向服务的特点 12345678graph LR subgraph 点到点的调用不能完全发挥面向服务的特点 A(SOAP); B(WSDL); C(XML Schema); D{点到点的调用}; A & B & C --- D; end 所以引入第三方（即服务注册），UDDI 是在 Web Service 服务栈中间标准用来对于服务注册进行支撑的协议。 1.2 作用 UDDI 被用来提供发布和查找 Web Service 的元服务。它可以用来针对丰富的元信息进行查找 UDDI 采用 XML 格式，来存放注册 Web Service 的描述性息，主要提供以下信息： WHO ：业务的基本信息（谁提供服务） WHAT ：分类信息（服务完成哪些功能） WHERE ：注册信息（哪里完成服务的调用） HOW ：关于服务接口的注册引用及其它属性（采用什么方式访问） UDD ...

1. SOAP 1.1 概念 SOAP 提供了一种标准的方法，使得运行在不同平台并使用不同的技术和编程语言的应用程序可以互相进行 XML 通信。从本质上来说，SOAP 并不是一个网络传输协议，它仅仅是一个信息传递的概念性框架，在实际使用时，需要绑定具体的网络传输协议和上层的应用逻辑来创建关联。 1.2 作用 SOAP 提供了基于 XML 的信息定义方式，用以在去中心化的分布环境中，提供点到点的结构化、带类型的信息交互。 SOAP 使用 XML 定义了可扩展的消息架构，该消息架构提供了能够基于多种底层协议，进行信息交换的信息架构。 该架构独立于具体编程模型以及其它的实现相关语义（至于具体如何使用网络协议进行传输，交给另外的协议，比如 SOAP Binding）。 SOAP 从概念上提供了单向、不带状态的消息交互范式。 SOAP 提供： 以可扩展方式传送应用相关信息的架构 SOAP 节点在收到 SOAP 消息后，所需要执行的必要操作 SOAP 不关心： 它所携带的应用相关数据的语义（就像信封不关心在信封中装的是支票还是邮件） 诸如 SOAP 消息的路 ...

1. 面向服务中的信息交换和数据类型 1.1 电子信息交换 定义 在执行领域（业务）相关功能时，各式各样、采用电子方式编码的信息，在软件单元之间的移动的过程。 分类 应用内部 - 信息在单个应用的不同部分之间移动 应用之间 - 信息在同一个企业系统中的不同应用之间 系统之间 - 信息在同一个企业的不同系统之间移动 公司之间 - 信息在不同的公司之间移动 交换方式 基于二进制的方式（与实现紧密相关） 基于平台相关的方式 基于语言相关的方式 基于文本的方式（文本能提供复杂的数据结构） 基于某种中介的方式 1.2 XML（信息交换方式） 平台中立、语言中立、基于文本结构、能够表达复杂数据结构 XML 及其相关协议在面向服务的计算中担任元数据的角色 XML 用途：服务使用 XML 消息进行发布/查询/调用。 描述服务（接口及流程） 描述查询服务的服务需求 描述服务的调用请求 其他在面向服务计算中所需要执行的信息交换 1.3 XML Schema（数据类型） 定义 使用 XML Schema 脚本来对 XML 消息应当符号满足的数据结构进行约定和描述 ...

1. 服务 1.1 定义 服务是为客户（担任协同提供者）所执行的非持久的，无形的体验。 服务是单个或一系列活动。这些活动或多或少带有无形的天然属性，通常（不是必须）在客户和服务雇员/物理资源和产品/服务提供者的系统之间的交互中所发生。它们用来提供针对客户问题的解决方案。 1.2 服务模型 vs. 制造模型 123456789101112131415161718graph LRsubgraph 服务模型 A((服务客户)) B[前台] C[后台] subgraph 服务提供者 C === B end B ---|双向关系| Aendsubgraph 制造模型 D((通用客户)) E[产品] subgraph 产品提供者 F["后台(工厂)"] end F --> E -->|未知关系| Dend 服务模型：服务的客户和服务的提供者之间的交互是双向的（相同的服务提供者面向不同的客户提供的服务是不同的） 制造模型：整个过程是单向的，产品并不是针对每个客户定制的 ...

1. 服务生态系统 1.1 服务组合 面向服务的应用逻辑，遵循面向服务的设计原则，采用服务和服务组合加以实现。 服务组合由多个装配在一起的服务所构成，用以提供对业务任务或过程进行实现的功能。 由于面向服务倾向于将服务打造为无关的企业资源，即服务和它的调用者之间是无关的，一个服务可能被多个消费者程序所调用，它们能在不同服务组合中组合同一个服务。 1.2 服务库存 服务库存是在组织或组织的合理部分边界内，一组独立标准化并治理的完备服务。 服务库存可以按照服务模型进行分层： 应用服务层：紧密和实现相关的较小功能单元抽象出来的服务。 业务服务层：直接满足调用者、消费者需求的服务 【根据实现、设计上的特征分类】 任务-中心：以任务为中心的业务服务（任务服务） 实体-中心：以实体为中心的业务服务（实体服务） 编排服务层：（可选的服务层）服务组合的一种实现，一般由领域专家实现，使用平台中立语言（文本化的标记语言，一般为 XML）来描述服务组合的业务逻辑。 在构建前，服务库存的蓝图就已设计完毕了。 服务库存的演化阶段： 初始服务交付项目（按需开发） 服务是中立 ...

1. 服务生命周期 1.1 基本阶段 面向服务的分析 面向服务的设计 服务的开发 服务的测试 服务的部署 服务的管理 1.2 业务逻辑/应用逻辑 业务逻辑源自于企业业务领域，也无需求的文档化实现 一般被构造为表达这些需求的流程 包括任何相关的约束、依赖及外部影响 应用逻辑是组织成不同技术解决方案的业务逻辑的自动化实现 【注】业务逻辑和应用逻辑可以认为是针对同一个问题在不同层级上的解决方案。 1.3 服务层次 服务生态系统服务可分为三个不同类别： 应用服务层：针对底层应用逻辑进行封装的服务 业务服务层：用来满足服务调用者的业务需求的服务 编排层：对业务服务采用编排方式加以实现（可选层） 【注】若将应用服务和业务服务在同一个服务接口中间加以实现，则称为混合（应用）服务。 1.4 面向服务的交付策略 自顶向下策略——分析优先 定义企业范围的相关本体（Ontology，领域知识的概念及其关联） 将相关的业务模型（包括实体模型）与新的或修订后的本体匹配 进行面向服务的分析 进行面向服务的设计 开发所需服务 测试服务及所有的服务操作 部署服务 【注】自顶向下 ...

1. 标准化服务合约 1.1 服务合约 建立了与服务交互有关的术语 提供了技术限制和需求，及服务的拥有者希望对外公布的所有语义信息 1.2 标准化服务合约 使用形式化或者标准化的合约 服务功能描述的标准化 服务数据表示的标准化 提倡尽量保持不同服务之间、在数据总体模型和特定数据类型之间的一致性 非标准化的服务数据表示将导致频繁的数据转换 Schema 被单独设计和实现，与使用它的服务操作分离 采用“Schema 集中化”的设计模式，倡导对每个信息集合定义一个“官方”的 Schema 可以将一个企业划分为多个分离的领域，每个领域都可以被独立地进行标准化和治理 除集中式的 Schema 外，也常常需要提供特定服务相关类型的额外的 Schema 服务策略的标准化 WS-Policy 定义为服务合约添加了一个单独的潜在抽象层次 使得逻辑能以单独的策略断言的形式存在于物理上独立的策略定义文档中 多层次的标准化 专用的断言词汇 参数和嵌套策略 策略的模块化和集中化 结构化标准 其他的设计原则也会直接影响到合约的定位、设计以及最终的使用 ...

更多快捷键请在 VSCode 中点击【设置】→\rightarrow→ 【键盘快捷方式】查看。 1. Ctrl + Shift + P / F1 调出命令面板。 2. Ctrl + K + C / Ctrl + K + U 注释代码/取消注释。 3. Ctrl + Shift + - / Ctrl + Alt + - 光标向前跳转到下一个位置/回退跳转到上一个位置。 4. Ctrl + F / Ctrl + H 查找/替换。 5. Ctrl + Shift + F / Ctrl + Shift + H 在文件中查找/替换。 6. Ctrl + N / Ctrl + O / Ctrl + S / Ctrl + Shift + S / Ctrl + W 新建/打开/保存/另存/关闭文件。 附录 Linux 下 VSCode 基本快捷键（Ctrl + K Ctrl + R） Windows 下 VSCode 基本快捷键（Ctrl + K Ctrl + R）