Jump to Navigation

Network

网络,互联网

grpc与http2的关系

grpc与http2的关系

grpc client 发送包到原生的http2 server

client收到报错:

panic: rpc error: code = 9 desc = transport: received the unexpected content-type "text/html; charset=UTF-8"

server端输出:

输出正常,包括了http2的所有信息,默认情况下响应了404。

gRPC半透明转发反向代理

gRPC半透明转发反向代理

转发需求说明

基于gRPC协议的网络服务代理层,能够起到正确转发请求的功能。

在真实运行环境情况中,服务可能表现的更离散,通过添加一个带路由功能的、行为一致的反向代理层, 有效减小客户端要考虑的不同处理机制,同时也简化了客户端的一些配置。

特性: * 半透明转发(相对于透明转发) * 自发现路由(相对于固定路由) * 多协议支持 * 协议不变规则 * 对等无状态

半透明转发

透明转发,指的是在转发TCP连接上,逐字节无修改的转发。这种转发适合后端一致,只开放一个出口的场景。

在该模块使用的半透明指的是需要对请求进行部分解析,解析出来请求的服务名称/路径信息,根据这一信息转发到合适后端。

请求包包含两个部分,对目前支持的协议来说,一个是头信息部分,一个是数据部分。

注意,这里的部分解析,只解析头信息部分,并不解析数据部分,因为gRPC协议的解析需要数据包相应的结构体, 而在代理层选择不带数据包的结构体,也就无法解析数据包了。这些数据包,只需要透明原样转发到后端即可。

对于部分解析的请求,确定转发后端后,重新构造新的请求,并发送到后端。

Category:

基于网络的准实时服务监控

基于网络的准实时服务监控

服务作为一个操作系统进程,可能由于程序本身的bug或者停机原因而退出服务。

对于OP系统来说,监控可以达到有效的知识及报警目的。

对于DEV来说,有时根本不需要,查找原因并重启一般人工介入。

但是对于一个更自动化了的完整系统来说,除了OP提供的监控与协助诊断之外,

也许可以实现DEV才能够实现的一种浸入式的监控,并在有监控事件时做精细准确的处理。

常用服务进程监控方式

一般采用第三方服务来监控服务进程的存活状态,并且一般使用OP的系统,如puppet,chef等。

这种方式的特点是一般运行运行在每个服务节点上,确保进程退出时能够通过操作系统API/命令检测到。

这种方式使用可靠成熟应用范围广泛的系统支持,一般还是非常可靠的。

浸入式服务进程监控方式

相比第三方监控工具,这种是把监控代码嵌入服务代码中,与服务共生联系紧密的。

这种不但能够检测进程退出问题,而且还能检测进程的异常假死情况,并且在出现这些情况时做出更精细准确的响应。

但这种方式是有些缺点的,开发稍微复杂,要对异常情况做出更精细准确的响应也是很大挑战。

etcd vs consul vs zookeeper 简单对比

etcd vs consul vs zookeeper 简单对比

这是目前在分布式一致性方面非常优秀的项目。

zookeeper:

使用posix协议,功能全面,但开发与维护复杂。采用java编写。

  • k/v存储,
  • 服务协调API,
  • 锁,
  • ephemeral Node
  • API,私有协议,语言绑定包括java/c/python,常用语言有,但并不容易添加新的语言封装。
  • 效率 W: 200/秒,R: 2000/秒
  • 协调规模:

可在此基础上实现: 服务注册,监控

consul:

使用raft 协议,功能全面,自带服务注册机制,开发简单,维护中等复杂程序。采用golang编写。

  • k/v存储,
  • 锁,
  • 服务注册,监控,
  • API采用HTTP REST
  • 效率 W: ?/秒,R: ?/秒
  • 协调规模:

可在此基础上实现: 服务协调API

开发支持election选主集群项目的几种不同实现方式

开发支持election选主集群项目的几种不同实现方式

election选主目前应用日趋广泛,但其算法复杂相对复杂,自已实现需要经历大量测试保证选举算法的正确与集群的稳定。

常用的选主算法有paxos, raft等。分别对应实现 zookeeper,etcd。

另外还有几个项目的实现了election选主并提供了相应的API,后面根据研究进展不断补充。

基于 etcd v2 版本实现,较通用的实现

这其实是一种依赖全局锁的实现方式,其实现的可靠性依赖与全局锁的实现。

比如,使用redis也可以实现这种,但是由于redis的非一致性集群特性,可能在极端情况下产生错误的状态。(虽然实际上redis很稳定)

unfair version

步骤,

1、以原子方式检查key不存在并且添加一个key。

2、如果操作成功能,则成为leader。

3、如果操作不成功,则watch该key的变化,过期或者被删除后再次执行leader选举功能。

letsencrypt安装

letsencrypt安装

前言

注意,要在域名已经指向到的服务器上才能安装。

letsencrypt会自动检测不同平台上的apache或者nginx包是否安装,以此生成对应证书。

还是使用mannal方式安装比较好,(git clone源码)。

mannual方式安装

第一步,使用certonly生成证书。

$ git clone https://github.com/letsencrypt/letsencrypt

命令,(先停止nginx服务,该命令执行过程中要使用80/443端口)

自建ngrok服务

自建ngrok服务

源代码

ngrok1.7及以下版本有源代码

ngrok2+版本没有源代码,但有bin版本。不知道是否有什么黑科技呢。

本文以有源代码的ngrok-1.7为例,说明自建ngrok服务的过程。

生成ngrok使用的自签加密证书

ngrokd客户端与ngrok客户端tunnel全程使用tls加密传输,所以要在编译前生成加密证书。

简单的生成脚本,

go实现gRPC的服务端的PHP扩展

go实现gRPC的服务端的PHP扩展

一种支持PHP语言编写gRPC服务端的方案

在有这个方案的想法时,并不确定技术上是否可行,只是觉得可行性程度挺高。

为了确认这可行性,先行做了些测试,所以先把技术点的可行性放在了文章的开头部分。

方案的设计将在总结可行性的基础上做详细说明,从本文的第二部分开始。

可行性验证

需要验证的主要有,

  • 从PHP调用go函数
  • 从go调用PHP函数
  • 把go代码编译为库
  • 把go库链接进PHP扩展
PHP调用go函数

上篇已经验证并实现。

用go实现PHP扩展

上篇已经验证并实现。

go调用PHP函数

如果需要go调用PHP函数,其实先要确定的是用C能够调用PHP函数。

好在我们有zend_API.h中的两个函数:

  • call_user_function
  • call_user_function_ex

而且比较成熟,不再多说明了。

一种PHP实现grpc协议调用grpc服务的方案

一种PHP实现grpc协议调用grpc服务的方案

原由

在前面的文章中,曾经提到grpc对PHP语言的支持情况。

主要是因为php-grpc的支持实现不完善,有明显的bug,支持落后于其他主要的开发语言。

从这个方向上考虑,如果要解决的话,需要完善php-grpc扩展,修复bug等,工作量可能比较大。

这段时间考虑到了一种临时替代方案,以解决在PHP中实现grpc协议调用服务的需求。

把使用go语言实现的客户端转换为PHP能调用的动态库

grpc对go语言的支持还是非常完善的,如果能够利用go的实现来支持PHP就好了。

刚开始只是考虑了一下,经过一些查找测试,发现这种方式真的是可行的,实际上已经有人实践过了。

最主要的是,这种方式还是go官方提供的,非常支持的方式,因为go语言有志于替代使用C/C++这类语言开发动态共享链接库。

这个实现方案的机制描述如下,

protoc-gen-go代码生成器的扩展

protoc-gen-go代码生成器的扩展

protobuf中的protoc命令简介

protobuf提供了描述格式标准,以及对应的格式解析工具及代码生成工具protoc。

由于protobuf支持众多不同编程语言,protoc被设计为插件式的程序,能够调用不同的插件,为.proto文件生成不同语言的执行框架代码。

go语言的protobuf实现

项目地址:https://github.com/golang/protobuf

目录结构:

Pages

Subscribe to RSS - Network


Main menu 2

by Dr. Radut