在 Kubernetes 发展初期,部署 Kubernetes 一直是一件让初学者头疼的事情,Kubernetes 也开始重视这个问题,2017年,在社区志愿者的推动下,社区发起了一个独立的部署 Kubernetes 的项目,kubeadm

经过一年多的发展,kubeadm 已经可以一键式进行 Kubernetes 集群的快速初始化和安装,极大地简化了部署过程。值得一提的是,在很长一段时间里 kubeadm 有个比较欠缺的地方是无法做到一键部署一个高可用的 Kubernetes 集群,这是 kubeadm 目前的工作重点,好在这个功能已经在 1.11 版本刚刚发布,可以参考 Creating Highly Available Clusters with kubeadm

阅读全文 »

endpoint 是一组 Pod 的集合的抽象,是 Kubernetes 里内置的资源类型,可以通过 Service 的 label 进行筛选得到。endpoint 往往伴随 service 诞生,对于定义 ExternalName 的 Service 或 clusterIP 直接定义为 None 的 Service(Headless Service) 来说,endpoint 也可以是不存在的。 endpoint 可以用来筛选出同 service 关联的所有 pod,将流量导入到 service 后,经过负载均衡的处理发送到这些 pod 上。

也可以单独定义 Endpoint 和 Service. 如果我们需要将 Kubernetes 集群之外的外部服务定义为 Kubernetes 内部的一个服务,可以分别定义 Service 和 Endpoints,Service 不需要定义标签选择器,定义一个与 Service 同名的 Endpoints,就可以与之关联。Endpoints 中的 subsets 中可以定义需要连接的外部服务器的 IP 和端口。

阅读全文 »

长轮询(long polling) Webhook
简述 利用 API 中的 getUpdates 方法, 如果 Bot 上次标记完成后没有收到信息,或消息已保存超过24小时,该方法会保持等待直到超时,在等待期间收到信息将会立刻返回结果;反之,该方法会返回一组包含了24小时内所有未标记信息的 Updates。利用 offset 参数可以将部分消息标记为已处理。 利用 setWebhook 方法告知服务器一个 url, 服务器将会在收到新消息时,通过 POST 方法将 json 格式的 Update 对象发送到指定的 url 地址。如果发送失败,Telegram 会重试一定次数。这个 url 必须是 https 的。
性能 没法做负载均衡,数据量比较大的情况话,性能瓶颈可能出现在 worker 上。 与传统服务器没有太大差异,可以做负载均衡(高可用),可以横向扩展。未来可以对接 Serverless,可扩展性更强
开发效率 不需要搭建服务器,不需要处理 https 证书,有一个机器人的 token 就可以在本地开发 在不搭建服务器的情况下,可以用 google script 开发,但只能用类 Javascript 语言。如果要用其他语言开发,需搭建服务器,需 https
交互体验 响应速度较 Webhook 慢 响应速度取决于网络延迟,体验一般比长轮询好

结论:如果追求开发速度,并且不需要考虑服务的高可用性,在可预知用户量不会增长过快的情况下,建议使用长轮询的方式,未来用户增长比较多再改也来得及,否则用 Webhook 的方式。如果对交互体验要求高的话,最好采用 Webhook 的方式。

前面的文章 go-ethereum 源码笔记(core 模块-世界状态,交易收据管理) 讨论了 geth 中对交易的处理,其中有一个阶段需要通过 EVM 执行,如果交易转入方地址为空,则调用 EVM 的 Create 函数创建合约;如果不为空,则为普通转账,调用 Call() 函数。这一篇我们将深入以太坊的虚拟机看看具体的过程。

这一篇需要对智能合约, ERC-20 标准,编译原理(了解编译器,解释器,虚拟机等概念),计算机组成原理(了解基于栈的虚拟机与基于寄存器的虚拟机的区别)有所了解。

阅读全文 »

通过前面的文章,我们了解了 geth 的大致原理,知道了区块链是怎么组织构成的,有了 rlp,MPT 这些数据结构的基础,也知道了账户是怎么组织的,交易是如何管理的,挖矿是一个什么样的流程,这一篇我们将深入到交易的具体处理过程,看看交易过程中是如何修改世界状态,生成交易收据的。

这篇文章将涉及到 core/types/transaction.go, core/state 模块,需要对交易池,账户等基本概念有所了解。

阅读全文 »