gitbook: Go 入门指南

gitbook:go-internals

gitbook:Go学习笔记(雨痕)

gitbook:Go Web 编程

blog

综合

年终盘点！2017年超有价值的Golang文章

语言&&语法

50 个 Go 开发者常犯的错误（英）
Go by Example

工具&&代码规范

go依赖包管理工具对比

持续集成服务 Travis CI 教程

[译]像牛人一样改进你的Go代码

编写地道的Go代码

使用 pprof 和火焰图调试 golang 应用

如何读懂火焰图？

Go调优神器trace介绍

碰过的问题

Killing a child process and all of its children in Go

package

思考

• 简单唯美,简单意味着可控稳定性，具体实现过程也要懂得间断停下思考，更好更简单的解决实现方法 很多情况在于 灵光一现。

• 提高思维层次，考虑尽量周全,业务功能角度,非业务功能角度，墨菲定律，你考虑到的实际情况肯定会发生（尤其在网络这方面），当然，有条件最好请教 有经验的人 可能疏忽哪些方面的考虑。

• 技术用来解决需求的，开始阶段，对业务的理解，需求合理性的质疑，做减法（避免过渡设计等等），系统往往都是根据需求迭代，逐步完善，开始阶段就考虑设计成最终形态（各种的完美），这本生就是不合理的需求。

• 宁可考虑久些，也不要没考虑清楚就盲目开始写，走一步分析一步，这种情况，往往效率低下，代码质量低；

• 分布式底层原理（万变不离其宗）

• 每个架构师都应该研究下康威定律

极客时间:陈皓专栏

• 陈皓的blog（coolshell.）,我想对于技术人，或多或少都有看过他的文章，文章深刻。
• 陈皓大神根据自己的资深实战经验来谈分布式系统的见解和思考，10几年的精华总结，干货满满，见解深刻，我想对于技术人都大有益处。

《大数据日知录__架构与算法》

• 看书名容易误认为主要讲大数据相关的，比如主要讲hadoop,hbase,spark等这几大代表项目。
• 从我角度看，是分布式系统的“百科全书”，质量比较高的书，整体上偏重技术架构方面，基本都覆盖了分布式系统中涉及到的算法，分布式资源调度，消息队列，分布式存储等等，都配有相对于的主流的开源项目，分析其框架原理，列出的文献资源也很好。
• 以本书为导向，配合coruseara 上视频，再到ｓｌｉｄｅｓｈａｒｅ上找相关的ｐpt，扩展学习了解相关的算法，无论了解新的分布式项目或者设计一个分布式系统，或多或少都会涉及到这些！
• 毕竟，对于分布式系统来说，相似的场景本质要解决的问题是相似的。

《分布式系统原理介绍》

主要是作者 自己在学习、开发分布式系统过程中获得的一些理论与实践进行总结（主要工程实践中应用广泛、简单有效的分布式理论、算法、协议数据分片,路由，副本协议，lease机制，一致性哈希，MVCC,两阶段提交，日记技术,CAP,paxos协议），是很不错的参考学习资料。

可参考 coruseara 相关视频:

• 《Cloud Computing Concepts》
• 《Cloud Computing Concepts: Part 2》

《大型网站技术架构：核心原理与案例分析》

通俗易懂，可以算是大型网站架构入门的科普。

《NoSQＬ精粹》

这是一本非常不错的 NoSQL领域入门书籍，通俗易懂，讲解nosql分类,使用场景，及其基本原理。

其他

• awesome-distributed-systems

• 分布式系统领域经典论文翻译集

• CNCF生态被业界认可，在容器编排领域，K8s已然是事实标准:

  • 部署方面：kubernetes及社区 已经能够简单快速的搭建和部署 ，这样才能更好的普及。
  • 稳定标准化方面：各种标准化被业界统一认可，核心功能整体架构等 趋于稳定；标准化某种意义就是避免被绑架。
  • 开发定制方面:整体架构的优雅灵活，系统可扩展性好，根据需求在不侵入源码下，可定制性强（client-go项目对开发友好），这样才能更好的解决各公司内部需求，实践落地成功。
  • 活跃度方面：贡献参与者多，社区活跃度高，各大公司的认可，无论存储，网络，容器方面都提供更多现成的选择，功能也越来越丰富，生态整体向好。

• 在kubernetes和docker两大生态竞争中，毫无疑问kubernetes已胜出,k8s已是大趋势。

• 开源也是场各大公司之间的博弈，无烟的战场，谁掌握了标准的制定，就占领了制高点,一言不合就可以让竞争对手举步维艰。

CNCF

Cloud Native Landscape

CNCF charter

CNCF 云原生容器生态系统概要

CNCF 云原生容器生态系统概要

• CNCF是一个开源Linux基金会，它致力于推进云端原生应用和服务的开发.
• CNCF 的一项重要承诺，就是为基于容器的各类技术的集成确立参考架。
• CNCF’s community believe there are three core attributes to cloud native computing:
  • Container packaged and distributed.
  • Dynamically scheduled.
  • Micro-services oriented.
• A cloud native computing system enables computing that builds on these core attributes, and embraces the ideals of:
  • Openness and extensibility.
  • Well-defined APIs at borders of standardized subsystems.
  • Minimal barriers to application lifecycle management.

容器标准（OCI）

OCI 和 runc：容器标准化和 docker

docker、oci、runc以及kubernetes梳理

• OCI（Open Container Initiative）
  • 是由多家公司共同成立的项目，并由linux基金会进行管理，致力于container runtime的标准的制定和runc的开发等工作。
  • 使命就是推动容器标准化，容器能运行在任何的硬件和系统上，相关的组件也不必绑定在任何的容器运行时上.
  • 目前主要有两个标准文档：容器运行时标准 runtime-spec和 容器镜像标准image-spec

• runc: 是对于OCI标准的一个参考实现.

• CRI(Container Runtime Interface)

  • kubernetes自己的运行时接口api,通过统一的接口与各个容器引擎之间进行互动。
  • 基于 gRPC 定义了 RuntimeService 和 ImageService，分别用于容器运行时和镜像的管理.
  • 与oci不同，cri与kubernetes的概念更加贴合，并紧密绑定。cri不仅定义了容器的生命周期的管理，还引入了k8s中pod的概念，并定义了管理pod的生命周期.

CNI(容器网络接口)

CNI

kubernetes指南:CNI

• Container Network Interface (CNI)最早是由CoreOS发起的容器网络规范，是Kubernetes网络插件的基础。其基本思想为：Container Runtime在创建容器时，先创建好network namespace，然后调用CNI插件为这个netns配置网络，其后再启动容器内的进程。现已加入CNCF，成为CNCF主推的网络模型.

CSI(容器存储接口)

CSI spce

Kubernetes存储介绍系列 ——CSI plugin设计

design-proposals:csi

• CSI是Container Storage Interface的简称，旨在能为容器编排引擎和存储系统间建立一套标准的存储调用接口，通过该接口能为容器编排引擎提供存储服务。
• 在CSI之前，K8S里提供存储服务是通过一种称为“in-tree”的方式来提供，这种方式需要将存储提供者的代码逻辑放到K8S的代码库中运行，调用引擎与插件间属于强耦合，持这套标准以后，K8S和存储提供者之间将彻底解耦。

markdown文件放在 github.com/yucs/yucs-awesome-resource 持续更新，欢迎star ,watch

如有出入请请教，文章持续更新中…

- docker :Docker从入门到实践

实践生态

请注意，容器技术圈已迈入后Kubernetes时代(好)

Kubernetes的工业级实践

干货视频 | Kubernetes在vivo容器云平台中的实践

部署

• 利用Ansible部署kubernetes集群： 官方kubeadm下载的镜像需要翻墙，国内网络环境下使用AllInOne部署更方便，单机多主机部署都支持。

  • 基于二进制方式部署和利用ansible-playbook实现自动化：既提供一键安装脚本，也可以分步执行安装各个组件，同时讲解每一步主要参数配置和注意事项。

  • 二进制方式部署优势：有助于理解系统各组件的交互原理和熟悉组件启动参数，有助于快速排查解决实际问题

schedule

• Kubernetes调度详解
• Kubernetes Scheduler是如何工作的
• kubernetes 调度器指北

API

• Kubernetes API 分析 ( Kube-apiserver )

• api-conventions

• Kubernetes deep dive: API Server – part 1

• Kubernetes deep dive: API Server – part 2
• ubernetes deep dive: API Server – part 3

controller

• kube-controller-manager 分析

event

• Kubernetes(K8s)Events介绍（上）
• Kubernetes Events介绍（中）
• Kubernetes Events介绍（下）
• kubelet 源码分析： 事件处理

operator

Operator：固化到软件中的运维技能

黄东旭DTCC2017演讲实录：When TiDB Meets Kubernetes

使用 Operator 来扩展 Kubernetes(视频)

• 部署这有状态的应用和部署管理它们会比无状态的复杂，是因为它们有这些复杂的运维和逻辑在里面。

• Operator 是跟应用紧密相关的，所以其中最重要的工作就是把应用自身的运维方法编码成为资源和控制逻辑。

• Operator的意义在于它其实是相当于使用了 Kubernetes 的 TPR（现在CRD）的 API，去把你的系统运维的一些领域知识，封装到 Operator 里面，然后把 Operator 这个模块注入到 Kubernetes 上面，整个这些集群是通过 Operator 这个模块来去做调度。

• Operator技术上就说通过CRD和controller来实现的。根据需求，与其他Pod等公民一样，先用CustomResources扩展添加新Resource,用controller来达到预期状态。
• 参考项目：redis-operator

CustomResources

kubernetes 指南：customresourcedefinition

官方相关文档： custom-resources, extend-api-custom-resource-definitions

kubernetes-deep-dive-api-server-part-3a

代码级例子 : extend-kubernetes-1-7-custom-resources

• 无需改变代码来扩展 Kubernetes API 的机制，用来管理自定义对象.

• For any new resource, you follow the same methodology:

  • Define the resource schema;
  • Register the resource with the API service and provide proper APIs;
  • Implement a controller which will watch for resource spec changes and make sure your application complies with the desired state.

Kubernetes Deep Dive: Code Generation for CustomResources

• 通过code-generator生成相关代码库包，来访问自定义的CRD，减少开发量(解决上面提的第二步：provide proper APIs)

controller

A Deep Dive Into Kubernetes Controllers

kubewatch-an-example-of-kubernetes-custom-controller

官方社区给出的开发controller指导： kubernetes/community:controllers

• Kubernetes runs a group of controllers that take care of routine tasks to ensure the desired state of the cluster matches the observed stat.(each controller is responsible for a particular resource in the Kubernetes world).

• 伪代码模型：

1
2
3
4
5

for {
  desired := getDesiredState()
  current := getCurrentState()
  makeChanges(desired, current)
}

• client-go包的Informer/SharedInformer

  • Informer/SharedInformer watches for changes on the current state of Kubernetes objects and sends events to Workqueue where events are then popped up by worker(s) to process.（从Kubernetes 1.7开始，所有需要监控资源变化情况的调用均推荐使用Informer。Informer提供了基于事件通知的只读缓存机制，可以注册资源变化的回调函数，并可以极大减少API的调用。）
  • Kubernetes Informer 详解

• 处理函数：

  • client-go包封装了获取事件变化和针对对异步的队列框架机制，我们只需实现处理逻辑接口：

  1 2 3 4 5

  type ResourceEventHandlerFuncs struct { AddFunc func(obj interface{}) UpdateFunc func(oldObj, newObj interface{}) DeleteFunc func(obj interface{}) }

• 官方参考模板：sample-controller（通过code-generator生成clientset等库）

其他相关开发资源

• client-go

  • 使用 client-go 控制原生及拓展的 Kubernetes API
  • 如何用 client-go 拓展 Kubernetes 的 API
  • client-go的使用及源码分析

• EventRecorder

  • controller需要将关键步骤中的执行事件发送到 apiserver，这样客户端就能通过查询知道整个流程发生了哪些事情.
  • Kubernetes(K8s)Events介绍（上）
    • Kubernetes Events介绍（中）
    • Kubernetes Events介绍（下）
  • kubelet 源码分析： 事件处理

–

markdown文件放在 github.com/yucs/yucs-awesome-resource 持续更新，欢迎star ,watch

如有出入请请教，文章持续更新…

• 存储选型思考

  • 一般应用服务：应用级本身不做数据的冗余，为了数据的安全性，而且这类读写延迟高些也能接受（读写IO路径长，多副本机制，都会增加读写延迟），开源的主流使用ceph（默认采用三副本，设计优雅，理念也是自动化）
  • 数据类服务：本身为了高可用而使用多副本冗余机制，通常对性能和延时有比较高的要求
    • 简单方案可以采用如hostpath等本地存储方案，妥协点是数据无法迁移（当然，一般数据类系统 添加删除节点时，本身有负载均衡功能，所以可以通过 删除节点，添加新节点 这种“迁移”方式，迁移过程就是对服务有可能所影响）
    • 使用网络块存储（block device）（性能高的SAN存储）: 跟平台解耦，灵活迁移，代价就是延时有些高，性能有些低（像couchbase 这类内存Nosql，数据在内存，通过异步刷新数据到磁盘 ，对磁盘读写延迟一些可以接受的）

• 开发存储插件

  • 背景：X银行往往有自己的高性能的SAN存储系统，需要进行对接，块设备挂载本地后使用LVM。
    • 基于FlexVolume: lvm 根据需求二次定制就好了。
    • （可选）参考external-storage:hostPath demo

• 参考TiDB关于本地存储的解决方案部分：黄东旭DTCC2017演讲实录：When TiDB Meets Kubernetes

概念

kubernetes指南：存储

官方文档

IBM开源技术微讲堂:Kubernetes的存储管理（好）

• volume :

  • Kubernetes Volume的生命周期与Pod绑定,容器挂掉后Kubelet再次重启容器时，Volume的数据依然还在.

  • 而Pod删除时，Volume才会清理。数据是否丢失取决于具体的Volume类型，比如emptyDir的数据会丢失，而PV的数据则不会丢. (官方文档: which is erased when a Pod is removed, the contents of a cephfs volume(其他网络存储一样，即PV) are preserved and the volume is merely unmounted.)

  • 限制：
    • 声明POD时，暴露出存储细节， 一般用户视角来说，可能不关心，有一定的耦合。
    • 不包含对第三方存储的管理：在声明POD前，对于第三方存储，要先创建好对应的volume,删除POD也需要手动删除volume资源。

• PV(Persistent Volumes)，PersistentVolumeClaim (PVC),StorageClass:

  • 为了解决volume的限制，更加方便自动化。
  • 概念：
    • PersistentVolume（PV）是集群之中的一块网络存储。跟 Node 一样，也是集群的资源。相对于 Volume 会有独立于 Pod 的生命周期（有 PV controller来实现PV/PVC的生命周期）。
    • 而PersistentVolumeClaim (PVC) 是对 PV 的请求,pod声明使用它。（ 从Storage Admin与用户的角度看PV与PVC :Admin创建和维护PV; 用户只需要使用PVC(size & access mode).
    • StorageClass来动态创建PV，不仅节省了管理员的时间，还可以封装不同类型的存储供PVC选用。就是封装了对第三方网络存储的管理操作，这样就不用手动创建volume或者手动声明一个PV。（所以，最灵活做法声明POD使用PVC,而PVC使用StorageClass）。

原理

IBM开源技术微讲堂:Kubernetes的存储管理

Kuberenetes 存储架构总体介绍

Kubernetes存储介绍系列 ——CSI plugin设计

Kubernetes存储介绍系列 —— AttachDetachController1

Kubernetes 存储功能和源码深度解析（一）

Kubernetes 存储功能和源码深度解析（二）
Kubernetes中的Persistent Volume解析

• Volume Plugins
  • 存储提供的扩展接口, 包含了各类存储提供者的plugin实现。
  • 实现自定义的Plugins 可以通过FlexVolume(K8s 1.8版本，目前算是过度方案)
  • kubernetes 1.9以后可能推荐CSI（Container Storage Interface）用方式来实现。
    • 支持这套标准以后，K8S和存储提供者之间将彻底解耦，终极目标是将存储的所有的部件作为sidecar container运行在K8S上（当前K8s 1.8版本设计还没有完全做到，需要一个兼容的发展周期），而不再作为K8S部件运行在host上。
• Volume Manager
  • 运行在kubelet 里让存储Ready的部件，主要是mount/unmount（attach/detach可选）
  • pod调度到这个node上后才会有卷的相应操作，所以它的触发端是kubelet（严格讲是kubelet里的pod manager），根据Pod Manager里pod spec里申明的存储来触发卷的挂载操作
    • Kubelet会监听到调度到该节点上的pod声明，会把pod缓存到Pod Manager中，VolumeManager通过Pod Manager获取PV/PVC的状态，并进行分析出具体的attach/detach、mount/umount, 操作然后调用plugin进行相应的业务处理

• PV/PVC Controller

  • 运行在Master上的部件，主要做provision/delete
  • PV Controller和K8S其它组件一样监听API Server中的资源更新，对于卷管理主要是监听PV，PVC， SC三类资源，当监听到这些资源的创建、删除、修改时，PV Controller经过判断是需要做创建、删除、绑定、回收等动作。

• Attach/Detach Controller

  • 运行在Master上，主要做一些块设备（block device）的attach/detach（eg:rbd,cinder块设备需要在mount之前先挂载到主机上，看源码看哪那些实现了Attah接口)
  • 非必须controller: 为了在attach卷上支持plugin headless形态，Controller Manager提供配置可以禁用。
  • 它的核心职责就是当API Server中，有卷声明的pod与node间的关系发生变化时，需要决定是通过调用存储插件将这个pod关联的卷attach到对应node的主机（或者虚拟机）上，还是将卷从node上detach掉.

• K8s挂载卷的基本过程

  • 用户创建Pod包含一个PVC
  • Pod被分配到节点NodeA
  • Kubelet等待Volume Manager准备设备
  • PV controller调用相应Volume Plugin(in-tree或者out-of-tree)创建持久化卷并在系统中创建 PV对象以及其与PVC的绑定(Provision)
  • Attach/Detach controller或者Volume Manager通过Volume Plugin实现块设备挂载(Attach)
    • Volume Manager等待设备挂载完成，将卷挂载到节点指定目录(mount)
    • /var/lib/kubelet/plugins/kubernetes.io/aws-ebs/mounts/vol-xxxxxxxxxxxxxxxxx
    • Kubelet在被告知设备准备好后启动Pod中的容器，利用Docker –v等参数将已经挂载到本地 的卷映射到容器中(volume mapping)

• PV & PVC状态图
  PV的状态图：
  
  PVC的状态图:
  

源码分析

Volume Manager : kubernetes数据卷管理源码分析

• kubelet管理volume的方式基于两个不同的状态：

  • DesiredStateOfWorld：预期中，pod对volume的使用情况，简称预期状态。当pod.yaml定制好volume，并提交成功，预期状态就已经确定.
  • ActualStateOfWorld：实际中，pod对voluem的使用情况，简称实际状态。实际状态是kubelet的后台线程监控的结果.

• vm.desiredStateOfWorldPopulator.Run方法根据从apiserver同步到的pod信息，来更新DesiredStateOfWorld。另外一个方法vm.reconciler.Run，是预期状态和实际状态的协调者，它负责将实际状态调整成与预期状态。预期状态的更新实现，以及协调者具体如何协调.

PVcontroller: Kubernetes 存储功能和源码深度解析（二）

开发资源

• volume plugin

  • 基于FlexVolume: lvm
  • 基于CSI：community:storage_design

• Out-of-Tree Provisioner

  • 由于在Pod中声明volume有局限性，要更灵活的化，就需要pv controller等进行生命周期的管理。
  • external-storage:hostPath demo

本文出处：https://yucs.github.io/2017/12/14/2017-12-14-kubernetes_volume/

markdown文件放在 github.com/yucs/yucs-awesome-resource 持续更新，欢迎star ,watch

如有出入请请教，文章持续更新中…

《分布式系统原理介绍》第一章

• 分布式系统模型：
  

• 异常是常态：分布式系统核心问题之一就是处理各种异常(failure)情况。

• TCP 协议保证了 TCP 协议 栈之间的可靠的传输，但无法保证两个上层应用之间的可靠通信，往往应用间需要确认消息。（使用RPC就可以在应用层确认消息，某种程度算是应用层的可靠通信）

  • 题外话：应用程序调用接口保存数据，返回成功也不一定意味着真实落盘，因为通常为了性能，不使用直写模式，数据只会写入操作系统内核缓存区就返回成功了，尤其使用分布式文件系统，IO路径更长。

• 由于网络异常的存在，分布式系统中请求结果存在“三态”的概念：成功、 失败、 超时(未 知)。对于超时的请求，我们无法获知该 请求是否被节点 B 成功执行了，因此要特殊处理，一种简单处理方式，就是调用接口要幂等性（分布式系统设计中，幂等性很重要，可以保证系统状态的正确性）。
  

• 在工程实践中，大量异常情况是无法预先可知的：例如，磁盘故障会导致 IO 操作缓慢，从而有可能使得进程运行速度非常慢，进而对整个系统会造成影响。又例如网络不稳定时也会引起“半死不活”异常，例如网络发生严重 拥塞时约等于网络不通，过一会儿又恢复，恢复后又拥塞，如此交替。

• 被大量工程实践所检验过的异常处理黄金原则是:任何在设计阶段考虑到的异常情况一定会在 系统实际运行中发生，但在系统实际运行遇到的异常却很有可能在设计时未能考虑，所以，除非需 求指标允许，在系统设计时不能放过任何异常情况。

• 工程中常常容易出问题的一种思路是认为某种异常出现的概率非常小以至于可以忽略不计。（墨菲定律：一、任何事都没有表面看起来那么简单；二、所有的事都会比你预计的时间长；三、会出错的事总会出错；
  四、如果你担心某种情况发生，那么它就更有可能发生。）

• 衡量分布式系统的指标
  • 可扩展性(scalability) : 指分布式系统通过扩展集群机器规模 高系统性能(吞吐、延迟、 并发)、存储容量、计算能力的特性。可扩展性是分布式系统的特有性质。分布式系统的设计初衷就 是利用集群多机的能力处理单机无法解决的问题.
  • 可用性：可用性是分布式的重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。
  • 性能指标：系统的吞吐能力，QPS(query per second)，系统的响应延迟。追求高吞吐的系统，往往很难做到低延迟;系统平均响应时间较长时，也很难提高QPS。(参考：吞吐量（TPS）、QPS、并发数、响应时间（RT）概念和系统吞吐量（TPS）、用户并发量、性能测试概念和公式)
  • 一致性: 分布式系统为了高可用性，总是不可避免的使用副本的冗余机制，从而引发副本一致性的问题。

Introduction to Distributed System Design

Introduction to Distributed System Design

彻底厘清真实世界中的分布式系统

当讨论分布式系统时，我们都会讨论些什么？

• 有关分布式计算的几个谬论: 网络是可靠的。延迟为零。带宽是无限的。网络是安全的。拓扑不会改变。肯定有一个管理员。传输的代价为零。网络是同质的。

• 常见异常：

  • Halting failures: A component simply stops. There is no way to detect the failure except by timeout: it either stops sending “I’m alive” (heartbeat) messages or fails to respond to requests. Your computer freezing is a halting failure.
  • Fail-stop: A halting failure with some kind of notification to other components. A network file server telling its clients it is about to go down is a fail-stop.
    Omission failures: Failure to send/receive messages primarily due to lack of buffering space, which causes a message to be discarded with no notification to either the sender or receiver. This can happen when routers become overloaded.
  • Network failures: A network link breaks.
    Network partition failure: A network fragments into two or more disjoint sub-networks within which messages can be sent, but between which messages are lost. This can occur due to a network failure.
  • Timing failures: A temporal property of the system is violated. For example, clocks on different computers which are used to coordinate processes are not synchronized; when a message is delayed longer than a threshold period, etc.
  • Byzantine failures: This captures several types of faulty behaviors including data corruption or loss, failures caused by malicious programs, etc.

• 分布式系统特性：

  • Fault-Tolerant: It can recover from component failures without performing incorrect actions.
  • Highly Available: It can restore operations, permitting it to resume providing services even when some components have failed.
  • Recoverable: Failed components can restart themselves and rejoin the system, after the cause of failure has been repaired.
  • Consistent: The system can coordinate actions by multiple components often in the presence of concurrency and failure. This underlies the ability of a distributed system to act like a non-distributed system.
  • Scalable: It can operate correctly even as some aspect of the system is scaled to a larger size. For example, we might increase the size of the network on which the system is running. This increases the frequency of network outages and could degrade a “non-scalable” system. Similarly, we might increase the number of users or servers, or overall load on the system. In a scalable system, this should not have a significant effect.
  • Predictable Performance: The ability to provide desired responsiveness in a timely manner.
  • Secure: The system authenticates access to data and services

很难设计出包含全部特性的分布式系统，因此在设计系统要根据具体需求做权衡了。尤其在数据类分布式系统，经典就是CAP，BASE,ACID理论了。

• 项目背景（XX银行客户）：私有云上要在K8S上跑像mysql这类状态的数据库服务，对性能和延时都比较敏感，并不像web偏应用的无状态延时性能差点可接受。而基于overlay方式等网络性能和延时比较差，网络架构又比较复杂。并且银行对于IP网络管理需要简单可控。SR-IOV是基于硬件实现虚拟网卡，性能损失少，接近宿主机，此外有支持QOS,vlan等特性也是客户需要的。即要根据用户定制基于SR-IOV网络插件。

• 问题： 目前kubernetes（1.8）（以后版本可能支持大）中，POD并没有网络相关的配置，kubelete 调用 CNI plugin 默认只会以CNI_ARGS传入pod_name基本信息。如果要固定分配IP地址，以及配置QOS,vlan等网络特性，没法通过CNI_ARGS方式传入，不能像volume一样在pod SPEC中配置options可选的网络参数来传入cni plugin。

• 一种可行解决方案：声明一个POD前，先根据pod_name来在外部configMap或其他地方存放网络配置信息，定制的CNI，IPAM的网络插件根据pod_name来从外部获取配置信息。

CNI工作原理

Kubernetes指南 cni

CNI：容器网络接口

• 网络插件是独立的可执行文件，被上层的容器管理平台调用。网络插件只有两件事情要做：把容器加入到网络以及把容器从网络中删除。
• 调用插件的数据通过两种方式传递：环境变量和标准输入。
• kubernetes 使用了 CNI 网络插件之后 工作流程：
  • kubernetes 先创建 pause 容器生成对应的 network namespace
  • 调用网络 driver（因为配置的是 CNI，所以会调用 CNI 相关代码
  • CNI driver 根据配置调用具体的 cni 插件
  • cni 插件给 pause 容器配置正确的网络,pod 中其他的容器都是用 pause 的网络.

Kubernetes的网络接口CNI及灵雀云的实践

• 运维人员视角，在传统运维工作强调对IP要有很强的管控（银行等），POD需要固定IP:
  • 于运维来说，网络方面是很重要的资源，要对IP进行强管控，服务来回飘，会让他的安全感下降很多。
  • 运维服务有很多基于IP的东西，有流量和突发的监控，如果你服务的IP一直变化，通过这个IP它很难用到这个服务，相当于IP的监控就没有意义，因为根本不知道IP流量上去了是哪个服务的，很难对应到这个事。
  • 还有是对于IP安全策略没有办法做。
  • kubelet 与 CNI plugin调用逻辑图：
    

• hackers-guide-kubernetes-networking
  • Kubernetes unfortunately still supports only one CNI interface per POD with one cluster-wide configuration. This is very limiting since we may want to configure multiple network interfaces per POD, potentially using different overlay solutions with different policies (subnet, security, QoS).
  • Kubelet will pass the POD name and namespace as part of the CNI_ARGS variable (for example “K8S_POD_NAMESPACE=default;K8S_POD_NAME=mytests-1227152546-vq7kw;” ). We can use this to customize the network configuration per POD or POD namespace (e.g. put every namespace in a different subnet).
  • Future Kubernetes versions will treat networks as equal citizens and include network configuration as part of the POD or namespace spec just like memory, CPUs and volumes. For the time being, we can use annotations to store configuration or record POD networking data/state.
  • multus-cni

• 从源码看kubernetes与CNI Plugin的集成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

  //kubernetes/pkg/kubelet/network/cni/cni.go
  func (plugin *cniNetworkPlugin) buildCNIRuntimeConf(podName string, podNs string, podSandboxID kubecontainer.ContainerID, podNetnsPath string) (*libcni.RuntimeConf, error) {
rt := &libcni.RuntimeConf{
ContainerID: podSandboxID.ID,
NetNS:       podNetnsPath,
IfName:      network.DefaultInterfaceName,
Args: [][2]string{
{"IgnoreUnknown", "1"},
{"K8S_POD_NAMESPACE", podNs},
{"K8S_POD_NAME", podName},
{"K8S_POD_INFRA_CONTAINER_ID", podSandboxID.ID},
},
}

 //libcni 
func (c *CNIConfig) AddNetwork(net *NetworkConfig, rt *RuntimeConf)
  invoke.ExecPluginWithResult(pluginPath, net.Bytes, c.args("ADD", rt))
    //将RuntimeConf.Args以环境变量方式传入。
    stdoutBytes, err := e.RawExec.ExecPlugin(pluginPath, netconf, args.AsEnv())


 type CNI interface {
AddNetworkList(net *NetworkConfigList, rt *RuntimeConf) (types.Result, error)
DelNetworkList(net *NetworkConfigList, rt *RuntimeConf) error

AddNetwork(net *NetworkConfig, rt *RuntimeConf) (types.Result, error)
DelNetwork(net *NetworkConfig, rt *RuntimeConf) error
}

type RuntimeConf struct {
ContainerID string
NetNS       string
IfName      string
Args        [][2]string
// A dictionary of capability-specific data passed by the runtime
// to plugins as top-level keys in the 'runtimeConfig' dictionary
// of the plugin's stdin data.  libcni will ensure that only keys
// in this map which match the capabilities of the plugin are passed
// to the plugin
CapabilityArgs map[string]interface{}
}

CNI开发参考资源

• CNI源码分析(比较系统)
• 深入理解CNI
• CNI spec 文档
• 官方维护的plugin插件: plugins
• 用cnitool 调试自己编写的plugin：cnitool
• 用脚本运行容器测试自己plugin:docker-run.sh
• 官方plugin sample:sample

kubelet原理

• Kubernetes指南 kubelet
• kubernetes 简介：kubelet 和 pod
  • 它的核心工作是监听 apiserver,配置目录(默认/etc/kubernetes/manifests/)等清单，一旦发现当前节点的 pod 配置发生变化，就根据最新的配置执行响应的动作，保证运行的 pod 状态和期望的一致。
    • 如果发现本地的Pod被修改，则Kubelet会做出相应的修改，比如删除Pod中某个容器时，则通过Docker Client删除该容器。 如果发现删除本节点的Pod，则删除相应的Pod，并通过Docker Client删除Pod中的容器。
  • 定时汇报当前节点的状态给 apiserver，以供调度的时候使用，通过cAdvisor监控节点和容器的资源。
  • 用“kubernetes/pause”镜像为每个Pod创建一个容器。Pause容器用于接管Pod中所有其他容器的网络。每创建一个新的Pod，Kubelet都会先创建一个Pause容器，然后创建其他容器。

kubelet源码分析

kubelet 源码分析：启动流程 （v1.5.0版本)

• 解析参数配置信息等初始化准备后， 创建kubeDeps这个对象：
  • 其实它内部保存了 kubelet 各个重要组件的对象，之所以要把它作为参数传递，是为了实现 dependency injection。简单地说，就是把 kubelet 依赖的组件对象作为参数传进来，这样可以控制 kubelet 的行为。比如在测试的时候，只要构建 fake 的组件实现，就能很轻松进行测试。KubeDeps 包含的组件很多，下面列出一些：
  • CAdvisorInterface：提供 cAdvisor 接口功能的组件，负责收集容器的监控信息
  • DockerClient：docker 客户端，用来和 docker 交互
  • KubeClient：apiserver 客户端，用来和 api server 通信
  • Mounter：执行 mount 相关操作
  • NetworkPlugins：网络插件，执行网络设置工作
  • VolumePlugins：volume 插件，执行 volume 设置工作
• RunKubelet 函数:
  • 通过 builder 创建出来 Kubelet对象（pkg/kubelet/kubelet.go#NewMainKubelet）
  • 根据运行模式，运行 Kubelet对象，各种组件以 goroutine运行启动
    • 异步事件驱动：syncLoop 是 kubelet 的主循环方法，它从不同的管道（文件、URL 和 apiserver）监听变化，并把它们汇聚起来。当有新的变化发生时，它会调用对应的处理函数，保证 pod 处于期望的状态。
• kubelet对象 中包含的重要对象：
  • podConfig：这个对象里面会从文件、网络和 apiserver 三个来源中汇聚节点要运行的 pod 信息，并通过管道发送出来，读取这个管道就能获取实时的 pod 最新配置
  • runtime：容器运行时，对容器引擎（docker 或者 rkt）的一层封装，负责调用容器引擎接口管理容器的状态，比如启动、暂停、杀死容器等
  • probeManager：如果 pod 配置了状态监测，那么 probeManager 会定时检查 pod 是否正常工作，并通过 statusManager 向 apiserver 更新 pod 的状态
  • volumeManager：负责容器需要的 volume 管理。检测某个 volume 是否已经 mount、获取 pod 使用的 volume 等
  • podWorkers：具体的执行者，每次有 pod 需要更新的时候都会发送给它
  • podManager：缓存了 pod 的信息，是所有需要该信息都会去访问的地方
  • nodeLister：能够读取 apiserver 中节点的信息

kubelet源码分析－启动运行与信息处理
kubelet 源码分析：pod 新建流程（v1.5.0版本)：

• pod的创建顺序留意点：
  • 创建 pod 的数据目录，存放 volume 和 plugin 信息
  • 如果定义了 PV，等待所有的 volume mount 完成（volumeManager 会在后台做这些事情）
  • 如果有 image secrets，去 apiserver 获取对应的 secrets 数据
  • 调用 container runtime 的 SyncPod 方法，去实现真正的容器创建逻辑
    • 通过 docker 创建出来一个运行的 pause 容器(Pause容器用于接管Pod中所 有其他容器的网络)。
    • 网络配置：如果 pod 是主机模式，容器也是；其他情况下，容器会使用 None 网络模式，让 kubelet 的网络插件自己进行网络配置。

文章出处： https://yucs.github.io/2017/12/06/2017-12-6-CNI/

markdown文件放在 github.com/yucs/yucs-awesome-resource 持续更新，欢迎star ,watch

如有出入请请教，文章持续更新中…

• 可以保证消息的完整性，但不能对消息进行认证 （可以辨别出篡改，无法辨别出伪装）
• 散列值得长度是固定的，和消息长度无关。
  
• 性质：
  • 根据任意长度的消息计算出固定长度的散列值。
  • 能够快速计算出散列值。
  • 如果两个消息体产生同个散列值称为碰撞,密码技术中所使用的单向散列函数必须具备抗碰撞性。
  • 哪怕只有1比特的改变，也必须有很高的概率产生不同的散列值
  • 
  • 具备单向性：
    
• 实际应用：
  • MD5来验证是否同个文件软件。
  • 数字签名处理过程非常耗时，因此一般不会对整个消息内容直接进行数字签名，而是先通过单向散列函数计算出消息的散列值，然后再对整个散列值进行数字签名。
  • SHA-1的抗碰撞性已被攻破。
  • SHA-256,SHA-384,SHA-512这些统称SHA-2，尚未被攻破。
  • SHA3简介：由于近年来对传统常用Hash 函数如MD4、MD5、SHA0、SHA1、RIPENMD 等的成功攻击2012年10月2日，Keccak被选为NIST竞赛的胜利者， 成为SHA-3。

数字签名

• 公钥密码和数字签名：
  
  
  

• 数字签名是对消息的散列值签名：
  
  

• RAS的数字签名和验证：
  
• 数字签名不能保证机密性，在数字签名中，只有发送者才持有生成签名的私钥，防止否认。
• 对称密码的密钥是机密性的精华，单向散列函数的散列值是完整性的精华。
• 数字签名是非常重要的认证技术，但前提是用于验证签名的发送者的公钥没有被伪造，即要确认公钥是否合法，可以对公钥施加数字签名，之就是证书。

证书

公钥证书（public-Key Certificate PKC）由可信的认证机构（certification Authority ,CA）施加数字签名。公钥证书也简称证书。

• 认证例子：
  

• 证书标准规范X.509:
  

简单例子：

1
2
3
4

#生成证书
openssl genrsa -out ca/ca-key.pem 1024  
#查看证书信息
openssl x509 -in cert.pem -noout -text

• 公钥基础设施（PKI）
  PKI(public-key infrastructure)是为了能够有效地运用公钥而制定的一系列规范和规格的总称。

  • 组成要素： 用户：使用PKI的人，认证机构（CA）：颁发证书的人 ， 仓库：保存证书的数据库：
    

  • CA的工作：
    

  • CRL(Certificate Revocation list): 证书作废清单，当用户的私钥丢失，被盗是，认证机构需要对证书进行作废。

• 认证机构的层次：
  

• 其他参考：

  • 数字证书原理：文中首先解释了加密解密的一些基础知识和概念，然后通过一个加密通信过程的例子说明了加密算法的作用，以及数字证书的出现所起的作用。
  • 那些证书相关的玩意儿:X.509,PEM,DER,CRT,CER,KEY,CSR,P12
    • CSR（Certificate Signing Request）：即证书签名请求,这个并不是证书,而是向权威证书颁发机构获得签名证书的申请。
    • PEM（Privacy Enhanced Mail）,打开看文本格式,以”—–BEGIN…”开头, “—–END…”结尾,内容是BASE64编码.

随机数-不可预测性的源泉

• 随机数用来生成对称密钥，公钥密钥。
• 性质
  • 随机性：不存在统计学偏差，完全杂乱的数列
  • 不可预测性：不能从过去的数列推测出下一个出现的数
  • 不可重复性：除非将数列本身保存下来，否则不能重现相同的数列.
  • 
  • 伪随机数生成器
    • 根据外部输入的种子生产伪随机数列
      
    • 伪随机数生成器是公开，但种子需要自己保密，这类似密码算法是公开，而密钥要自己保密。
    • 具体的伪随机数生成器
    • 很多伪随机数生成器的库函数使用线性同余法编写，但是不具备不可预测性，不能用于密码技术。
      
    • 用密码实现伪随机数生成器
      

小结

• 密钥是机密性的精华
• 散列值是完整性的精华
• 种子是不可预测性的精华
• 如果量子密码计算机进入实用领域，就能产生完美的密码技术
• 如果量子计算机比量子密码先进入实用领域，则使用目前的密码技术所产生的密文将全部破译。
• 即使真的拥有完美的密码技术，也不可能实现完美的安全性，因为必须会有人类-即不完美的我们参与其中。

密码技术概要图

术语

• 伪随机生成器：是一种能够模拟生产随机数列的算法,承担着密钥生成的重要职责。如果生成随机数的算法不好，窃听者就能推测出密钥，从而带来通信机密性下降的风险。

• 数字签名：是一种能够保证完整性，提供认证，并防止否认的密码技术。

• 对称密码： 在加密和解密，使用同一个密钥的方式。

• 公钥密码/非对称密码: 是指在加密和解密时使用不同密钥的方式。

• 单向散列函数/哈希值/密码校验/消息摘要:所保证的并不是机密性，而是完整性.

密码与信息安全常识

任何密码总有一天都会被破解

密码只是信息安全的一部分

不要使用保密的密码算法

• 密码算法的秘密，早晚会公诸于世！一旦密码，算法，详细信息被披露，依靠对算法本身进行保密，来确保机密信息的，密码系统也就土崩瓦解了。
• 开发高强度的密码算法是非常困难的。现在世界上公认的被认为强度较高的密码算法，几乎都是通过密码破译者长期还是破解未果而终活下来的。
• 试图通过对密码算法本身进行保密，来确保安全性的行为，一般称之为隐蔽性安全性，这种行为是危险且愚蠢的。

使用低强度的密码比不进行任何加密更危险

• 容易让用户通过“密码”这个词，获得一种错误的安全感，进而导致用户在处理一些机密信息的时候麻痹大意。

对称密码

通过XOR（异或）就可以实现高强度的密码

• 将明文A用密钥B进行加密，得到密文（A XOR B）
• 将密文（A XOR B）用密钥B进行加密，得到明文A
• 形象图参考如下：
  
• 参考链接：XOR 加密简介

DES，三重DES

• DES(Data Encryption Standard)，即数据加密标准，是1977年美国联邦信息处理标准中所采用的一种对称密码。一直以来被美国以及其他国家的政府和银行等广泛使用，但是随着计算机的进步，现在的DES已经能够被暴力破解，强度大不如前了，现在我们不应该再使用DES了。

• 现在DES已经可以在现实的时间内被暴力破解，三重DES出于这个目的被开发出来的,但是处理速度不高，而且在安全性方面也逐渐显现出一些问题，也不推荐使用。

  AES

• 美国国家标准技术研究所 用 高级加密标准（Advanced Encryption Standard: AES）,用以取代DES。 最终经过安全性分析、软硬件性能评估等严格的步骤，Rijndael算法。

• AES加密算法的详细介绍与实现: AES为分组密码，分组密码也就是把明文分成一组一组的，每组长度相等，每次加密一组数据，直到加密完整个明文。

  • 加密流程图：
    

小结

• 然而用对称密码进行通信时，还会出现密钥的配送问题，及如何将密码安全的发送给接收者。为了解决密码配送问题，我们需要用公钥密码技术。
• 使用一种密钥空间巨大，且在算法上没有弱点的对称密码，就可以通过密文来确保明文的机密性，巨大的密钥空间能够抵御暴力破解，算法上没有弱点可以抵御其他类型的攻击。

分组密码的模式

• 分组密码：是每次只能处理特定长度的一块数据的一类密码算法，这里的“一块”就称为分组（block）；一个分组的比特数就称为分组长度（block lenght）
  • AES的分组长度可以从128比特,192比特和256比特进行选择，当选择128比特的分组长度时，AES一次加密128比特的明文，并生成128比特的密文。
• 分组密码模式：分组密码算法只能加密固定长度的分组，但是我们需要加密的明文长度可能会超过分组密码的分组长度，这时就需要对分组密码算法进行迭代，以便将一段很长的明文全部加密。而迭代的方法就称为分组密码的模式（mode）。
  
  
• 分组密码有很多种模式，如果模式选择不恰当，就无法保证机密性。ECB模式中，明文中的一些规律就可以通过密文被识别出来。
• 安全性最差的模式是ECB模式，推荐使用CTR模式。

公钥密码

• 公钥密码（piblic-key cryptography）中，密钥分为加密密钥和解密密钥两种。加密密钥称为公钥，解密密钥称为私钥（private key）。公钥和私钥是一一对应的，一对公钥和一对私钥统称为密钥对（key pair）。

• 对称密钥存在配送问题：
  

• 使用公钥密码 解决了配送问题 (但存在公钥认证问题)：
  

RAS

• RSA算法基于一个十分简单的数学难题：RSA使用因式分解的原理，两个大质数相乘很容易，但大数分解质因子很难.即：将两个大质数相乘十分容易，但是想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥。

ECC（椭圆曲线密码）

• 通过将椭圆上的特点点进行特殊的乘法运算来实现，它的特点是所需的密钥长度比RSA短.

小结

• 使用公钥密码能解决密钥配送的问题，现代计算机和互联网所使用的密码技术都得益于公钥密码。
• 公钥密码是基于数学上的困难的问题来保证机密性。可见，对称密码和公钥密码是两种根本不同的思路。
• 公钥密码解决了密钥配送问题，但针对公钥密码能够进行中间人攻击。
• 密钥的价值等价于明文的价值
• 密钥生成：生成密钥的最好方法是使用随机数，因为密钥需要具备不易被她人推测的性质。密码学用途的伪随机数生成器必须是专门针对密码学用途而设计的。
• 密码配送：使用公钥密码外，还有一种是Diffie-Hellman 密钥交换。

高深的密码学+复杂的区块链，其实也可以通俗易懂:

• RSA又慢又不安全，所以比特币和以太坊都不采用，而是使用了更安全的椭圆曲线算法。
• ECC来做非对称加密基础算法。ECC算法用很短的密钥就能达到RSA2048的安全强度，而且计算速度有数量级的提高，所以目前应用很普遍，国密中的SM2就是基于ECC算法的。
• 强烈不建议使用RSA，原因如下：
  • 容易被破解：RSA-768可以在3个小时内破解，1024在理论上100小时内也可以破解。所以使用RSA，长度起步要2048。但是数学家彼得·舒尔研究了一个针对整数分解问题的量子算法 (舒尔算法)，理论上破解2048的RSA在100秒之内(好在量子机还未投入使用)。
    • 密钥长度加到2048可以提升安全，但是计算过慢。

混合密码系统

• 公钥密码的处理远远低于对称密码

• 公钥密码难以抵挡中间人攻击

• 混合密码系统: 结合对称密码，公钥密码和伪随机生成器这三种密码技术，创造出了一种兼具对称密码和公钥密码优点的密码方式。混合密码系统解决了公钥密码速度过慢的问题，并通过公钥密码解决了对称密码的密钥配送问题。密码软件PGP、以及网络上密码通信所使用的SSL/TLS都运用了混合密码系统。

  加密流程：

  

  • 伪随机数生成器被用于产生会话密钥。
  • 用对称密码加密消息，用公钥密码加密会话秘钥。即:会话秘钥是对称密码的密钥，同时也是公钥密码的明文。

    解密流程：

  • 

小结

• 混合密码系统中运用了对称密码和公钥密码两种密码方式，无论其中任何一方的密钥过短都可能遭到集中攻击，考虑到长期运用的情况，公钥密码的强度应该要高于对称密码，因为对称密码的会话密钥被破译只会影响本次通信内容，而公钥密码一旦被破译，所有相同公钥加密的通信内容就都能被破译了。

• 语言只是个工具，往一个具体领域学习研究才是王道：（当然，具体项目选择语言还是很重要的：该语言开发效率，性能，可读性，现有可用库是否满足项目等等语言生态环境，就看如何trade-off选择了），所以我不太喜欢用Python工程师，golang工程师来给工程师打标签，而ios/前端/web后端/分布式系统 这样带有领域方向的标签才合适。

• 不要抵触学习新语言心理，按需学习：无论开源项目,还是项目开发选中的语言，毕竟都有它的优势，需要就学习，毕竟学习一门语言也不会太耗时间（因为我想学语言最耗时间的在于学习库,无论语言，语言特性，语言背后的原理，都能很快就学习掌握的,尤其学习c++后，毕竟主流语言基本都是面向对象，而精髓是万变不离其宗，重要的还是抽象 即 理解掌握‘设计模式’的核心思想)，也能加深对语言的理解，发现自己真正欣赏动心的语言。

• 现在开发语言都在相互借鉴学习，个人觉得发展趋势：追求简洁性，开发效率，兼顾性能，更加注重业务逻辑，而非语言本生带来的心智负担（eg:语法层面引用代替指针或者如golang语言弱化指针，垃圾回收机制）。

• 个人觉得深刻学习语言最好的方式就是： 看用该语言写的开源项目源码，当然这涉及到动力问题，所以去研究自己感兴趣的领域，开源项目就很重要的，无论是工作需要，还是自己兴趣，以我为例，大学刚开始工作时候，研究linux内核开发，glusterfs分布式系统,也就学习C/C++，shell脚本了，学习初步研究openstack时候就学习python，研究docker也就学习了golang语言。

如何写出质量高的代码

• 最基本：理解语言底层原理，而不是简单的使用

• 看用该语言写的开源项目源码

  • 看逻辑流程时适合小中断，多注意源码组织布局，多注意该 类/模块 其他函数（封装/抽象）,猜测该类模块基本功能，这样我想对于项目组织理解会更深刻，能潜移默化的提高你代码的质量。

  • 高质量代码看多了，对代码品味高了，自己的写的代码质量当然也差不了多少，此外还能。so,我相信经常看开源项目的人写出来的代码质量都不会差的。

  • 能学到使用该语言的技巧，间接学习丰富该语言的库等等，肯定都有很多让自己眼睛一亮，学习借鉴的地方，这样写自己代码就有底气自信多了。

• 就如不懂github就不是一个合格的工程师一样， 某种意义讲，没有看过开源源码的也不算是个合格的工程师。

• 理解掌握 设计模式的核心思想：

  • 封装变化（抽象)
  • 多用组合，少用继承
  • 针对接口编程，而不针对实现编程。

• 对于go语言，看开源项目，多关注代码组织结构时，也多注意包中的*_test.go，在没没文档情况下，相对容易理解该包作用。

语言对比理解

• c/c++： 偏向底层基础软件，编译性语言，高性能，嵌入式等方向，指针，无垃圾回收机制，开发效率相对低，有一定的心智负担，可以理解为高级语言中的汇编语言

• python：追求开发效率，解释性语言，性能相对低，The Zen of Python,可用于脚本开发

• java: 成熟稳定，生态环境比较好，编译性语言，语法冗长，可用于企业级应用开发，性能高的基础软件，大数据生态。。很多大公司稳妥的选择。

• golang:（个人）设计优雅，interface接口的设计很好的面向对象的思想，工程性开发语言（语言层面有一定的强制性风格要求），编译型基于goroutine和channel的通信（语言层面支持）简洁高效的支持多并发，可用于高性能高并发系统开发

• scala: 函数式编程，追求速度，跑在JVM上，Java互操作性， 不可变，无副作用，函数是一等公民等函数式编程思维方式跟面向对象思想有一定的区别，对于开发人能力相对比较有要求。个人觉得对于函数式编程思想，对于数据的处理更贴近。。用于大数据领域（python ,java，scala对比：Scala 是一门怎样的语言，具有哪些优缺点？紫杉的回答）

资源推荐

golang

• 学习推荐书籍（golang ,web ,机器学习) golang 部分

java

• 《java编程思想》（Think in java）
  有深度精炼的书，不适合新手比，但提升必看的书（较有深度的书），层面设计也多跟C++做对比，比较深度的分析讲解面向对象的编程理念（即更多解释WHY 这么设计，而非只是语法层面）。
• 《java核心技术 卷一》
  适合新手看，中规中矩，语法层面更细些。

scala

• Scala课堂&&Effective Scala
• 《scala编程(Programming in Scala)》&&《快学scala》
• 可以参考 https://github.com/jacksu/utils4s 中 scala语法学习 资源部分
• Scala 是一门怎样的语言，具有哪些优缺点？&为什么选择Scala，它在大数据处理方面有何优势？