TCP协议作为整个OSI协议栈中最重要的协议之一，其复杂度也是数一数二的。由于TCP协议需要在不可靠的IP协议基础上的实现可靠的有顺序的传输，自然就决定了TCP提供了很多复杂的特性来实现这一目标。笔者从大学开始陆陆续续接触了TCP相关知识，但是始终没能形成一个知识体系，所以想借助这篇文章对整个TCP协议有一个更加全面的认识。

TCP提供了数据块切分、数据报文接收成功确认、超时重传、首部和数据的校验、报文片段的重排序、拥塞控制等机制。关于TCP连接的细节以及可靠性保障机制会在后文中做详细介绍。

  就在前不久的8月1号，Istio正式发布1.0版本。1.0版本相对较0.8版本在性能方面有较大提升，并且将支持多个 Kubernetes集群添加到单个网格中升级为beta版本、新增支持增量上线双向TLS以及Mixer支持开发进程外适配器等新特性。从最初的0.1版本到今天1.0版本，一共经历了一年多的时间，Istio的快速发展以及各大公司的跟进说明了Istio的理念和技术逐渐得到众多公司的青睐，Istio的未来真是不可限量。

与nginx的比较

  Nginx作为老牌的反向代理web服务器。高性能、良好的稳定性和扩展性一直是其受到各大技术厂商作为网络代理的首选。但是随着微服务架构的兴起，相对envoy，nginx在以下几方面有明显的劣势：

1. 开源版本不支持动态配置，配置需要reload才能更新。
2. 开源版本不支持高级的负载均衡算法。
3. 扩展性不如envoy，envoy的配置都是通过xds系列API暴露出来的，可以用任何语言进行实现。nginx的扩展性主要还是靠openresty此类的发行版本用lua脚本的方式进行高级功能的定制化开发，要求开发人员必须要会lua才行。
4. 对service mesh的支持不如envoy，这个就不用说了，Istio就是用envoy来做sidecar。nginx也推出了基于nginx的service mesh解决方案，不过目前还是预览版本。

5. 不支持上游的HTTP/2透明代理，目前仅支持HTTP/2下游连接。

   阅读全文 »

  前文我们提到过Service mesh分为control plane和data plane两个平面，data plane负责服务间的通信管理，而control plane负责策略配置收集监控数据鉴权等事项。严格意义来讲Istio只具有控制平面的功能，而在Istio中的data plane的功能是使用另外一个开源项目envoy来时实现的。这里为了不混淆，下文中的Istio只包括其control plane，而data plane使用envoy进行专指。前文已对Istio做完基本的介绍，按照正常的套路就应该介绍Istio的安装，但因为Istio的安装很简单，这里就不再赘述，大家可以移步https://istio.io/docs/setup/kubernetes/quick-start/。不过我们在安装的时候遇到几个问题可以在这里需要提一下：

• 安装istio时建议测试环境和没有外部业务通信的场景下建议不启动auth组件；
• 安装sidecar可以选择使用istioctl 命令行工具手动将sidecar注入到应用所在的pod，或者使用Istio Initializer每次在创建pod的时候自动将sidecar注入到业务容器所在那个pod里面
• 由于我们的k8s环境不支持loadbalance类型的TYPE，而istio-ingressgateway默认使用这个类型，导致在启动的时候pod都一直处于Pending状态，后来手动将类型改为nodeport，就可以正常启动。

Istio组件介绍

  说完Istio的整体，那我们再看看看Istio的各个组件，先上一张官方文档里面的图：

图片来自https://istio.io/docs/concepts/what-is-istio/overview/

  从接触英语开始，时态一直我都傻傻分不清，这块一直很模糊，最近在网上看到一个讲解，我觉得还不错，这里整理分享出来，便于和我有一样苦恼的人快速了解。

  英语一共有12个时态，以这样的一个实际场景来举例：朋友告诉你他们去还上寻找秘密的海上生物的任务，下文在此前提下展开对话：

什么是Service mesh

  Service mesh即“服务网格”，是一种用于处理服务到服务通信的专用基础设施层，它提供一个在不同服务实例间可靠的，弹性可伸缩的高性能通信服务。

  Service mesh为啥突然在这个时候这么火？这肯定是有原因的，就像AI实际上在上个六十年代就已经被提出但直到近几年才火起来是和云计算和大数据的普及密不可分一样，Service mesh的流行和微服务以及容器技术的逐渐成为技术架构的主流方式有关。随着微服务以及容器技术的逐渐普及，一个应用内部可能包含了上百个服务，而每个服务又有多个实例同时在运行，并且由于这些服务实例一般都是被K8s这样调度系统进行管理，所以实例一直处于不断变化的不稳定状态中。这样就导致服务与服务间的通信变得极为复杂。如何保证微服务场景下仍然可以进行高效可靠端到端的网络通信？提供一个专用的服务实例通信基础设施已经成为cloud native应用开发中的一个重要刚需。于是，上帝说要有光，那Service Mesh就应运而生。Service mesh为服务实例间网络通信提供监控、安全、认证和授权，以及降级限流等微服务的治理高级功能。

  在Service Mesh的具体实现中，其表现形式一般是提供一个Agent实例，service mesg称之为sdiecar（跨斗），sidecar会和服务实例部署在一起,sidecar将内部服务通信、安全认证相关、监控、容错等和业务本身并无关系的业务逻辑抽象出来，这样开发人员可以集中精力进行业务代码开发，而微服务治理等工作则交给运维人员进行后续维护和处理。具体架构参照下图：

图片来自：http://philcalcado.com/2017/08/03/pattern_service_mesh.html

完成对xml配置文件的解析和加载后，就可以进行bean的加载了，bean加载功能逻辑远比解析要复杂得多，spring中加载bean可以用过以下方式

1

MyTestBean bean = xmlBeanFactory.getBean("myTestBean");

AbstractApplicationContext.java

1
2
3
4
5

@Override
public Object getBean(String name) throws BeansException {
	assertBeanFactoryActive();
	return getBeanFactory().getBean(name);
}

1 解析默认bean标签

在上一篇博客中，最后调用了parseBeanDefinitions()方法，bean标签的解析便是在该方法内进行的，参照以下代码
DefaultBeanDefinitionDocumentReader.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
	if (delegate.isDefaultNamespace(root)) {
		NodeList nl = root.getChildNodes();
		for (int i = 0; i < nl.getLength(); i++) {
			Node node = nl.item(i);
			if (node instanceof Element) {
				Element ele = (Element) node;
				if (delegate.isDefaultNamespace(ele)) {
					parseDefaultElement(ele, delegate);
				}
				else {
					delegate.parseCustomElement(ele);
				}
			}
		}
	}
	else {
		delegate.parseCustomElement(root);
	}
}

1 资源封装

在java中，将不同来源的资源抽象成URL，通过注册不同的Handler（URIStreamHandler）来处理不同来源的资源的读取逻辑，一般handler使用不同前缀（协议，protocol）来识别，如”file:”、”http:”、”jar:”，然后URL没有默认定义相对ClassPath或ServletContext等资源的handler，虽然可以注册自己的URLStreamHandler来解析特定的URL前缀，比如”classpath:”，但URL缺乏一些基本的方法，如检查当前资源是否存在、检查当前资源是否可读等方法。

因此Spring对其内部用到的资源实现自己的抽象结构：Resource接口来封装底层资源，resource接口抽象了所有Spring内部使用的底层资源：File、URL、Classpath等，并且增加了几个使用的方法，例如定义了判断当前资源状态的方法：存在性（exists）、可读性（isReadable）、是否处于打开状态（isOpen）。另外，resource接口还提供了不同资源到URL、URI、File类型的转换，并且提供了获得lastmodified属性名、文件名（不带路径信息的文件名，getFilename()）的方法。

当通过Resource相关类完成了对配置文件进行封装后配置文件的读取工作就全权交给XMLBeanDefinitionsReader来进行下一步的处理

声明变量

声明变量的一般形式是使用var关键字,格式如下：

1

var identifier type

第一种，制定变量不赋值，则使用默认值

1

var a string

第二种，根据值自动判断变量类型

1

var b = 10

第三种，省略关键字var及变量类型，使用:=进行变量赋值

1

c := 100

声明数组

声明数组的格式如下：

1

var variable_name [SIZE] variable_type

例如以下声明一个长度为10的float32类型的数组

1

var balance [3] float32

初始化数组

1

var a = [3]float32{1.0, 2.0, 3.0}

初始化数组中 {} 中的元素个数不能大于 [] 中的数字。
如果忽略 [] 中的数字不设置数组大小，Go 语言会根据元素的个数来设置数组的大小。

HDFS的设计理念

• 超大文件，“超大文件”在这里是指具有几百MB,几百GB甚至几百TB大小的文件
• 流式数据访问，HDFS的构建思路是：一次写入，多次读取是最高效的访问模式，数据集通常由数据源生成或从数据源复制过来，接着长时间在此数据集上进行各种分析。每次分析都将设计该数据集的大部分数据甚至全部
• 商用硬件，Hadoop并不需要运行在昂贵且高可靠的硬件上。
• 低时间延迟的数据访问，HDFS是为搞数据吞吐量应用优化的，这可能会以提高实践延迟为大家，对于低延迟的访问需求，HBase是更好的选择
• 大量小文件HDFS能够存储的文件数受限于namenode的内存容量
• 多用户写入，任意修改文件，HDFS的文件写入只支持单个写入者，而且写操作总是以“只添加”方式在文件末尾写数据。它不支持多个写入者操作，也不支持在文件的任意位置进行修改

HDFS的概念

数据块

Hadoop也有类似磁盘文件系统的“数据块”概念，默认为128MB大小。对分布式文件系统中的块进行抽象会带来以下几个好处：第一，文件的大小可以大于网络中任意一个磁盘的容量。第二，使用抽象块而非整个文件作为存储单元，大大简化了存储子系统的设计（例如简化存储管理块的大小是固定的，因此计算单个磁盘能够存储多少个块就相对容易）。同时也消除了对元数据的顾虑（块知识要存储的大块数据，而文件的元数据，如权限信息，并不需要与块一同存储）

namenode和datanode

HDFS集群的两类节点以管理节点-工作节点模式运行，即一个namenode(管理节点)和多个datanode(工作节点)。namenode管理文件系统的命名空间。它维护者文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件和编辑日志文件。namenode也记录着每个文件中每个块所在的数据节点信息。这些信息并不是永久保存，因为这些信息会在系统启动时根据数据节点信息重建
datanode是文件系统的工作节点，他们根据需要存储并检索数据块，并且定期向namenode发送他们所存储的块的列表

未完待续…