Protocol Buffers

Apache Pulsar 是 2016 年 yahoo 开源的下一代大规模分布式消息系统，目前已经加入 Apache 基金会。在 Yahoo 的生产环境中大规模部署并使用了近 4 年，服务于 Mail、Finance、Sports、Flickr、the Gemini Ads platform、Sherpa 以及 Yahoo 的 KV 存储等，在 Yahoo 全球 8 个数据中心之间维护了全联通的复制，并支持了 200 多万个 Topics。 Apache Pulsar 有几个明显区别于其他消息系统的特点： 优秀的数据持久性和顺序性。每一条消息都提供了全局唯一的 ID，多副本，并都是在实时刷盘后再返回给用户。 统一的消费模型： 支持 Stream （如 Kafka ）和 Queue （如 RabbitMQ ）两种消费模型， 支持 exclusive、failover 和 shared 三种消费模式。 灵活的扩展性： 节点扩展的线性和瞬时完成，在扩展中不会有数据的拷贝和迁移。 高吞吐低延迟，在实时刷盘的前提下，依然提供了高带宽（ 180 万 messages/ 秒）和低延迟（ 5ms at 99%）。 Pulsar 2.1 更加了丰富消息系统之外的“ Stream Native ”的属性，比如 Schema 的支持， 层级存储， 状态函数等。。 =========== 今天

背景 某线上日志收集服务报警，打开域名报502错误码。 收集服务由2台netty HA服务器组成,netty服务器将客户端投递来的protobuf日志解析并发送到kafka，打开其中一个应用的日志，发现如下报错： org .apache .kafka .common .errors .TimeoutException: Expiring 1 record(s) 在排除了netty服务的错误之后，去查看kafka的日志。 发现报错，排查过程如下； 配置信息 系统 kafka版本 broker数量 CentOS7.4 2.1.0 3 线上有三台Kafka Broker，id分别为0、1、2，服务器只部署了Kafka服务。 问题 线程是否存活 首先jps查看Kafka线程是否存活，三台机器都没问题，kafka依然在运行。 GC问题 查看kafkaServer-gc.log.1.current的日志，gc日志没发现异常。 Broker 0/server.log [2019-08-02 15:17:03,699] WARN Attempting to send response via channel for which there is no open connection, connection id 172.21.3.14:9092-172.21.3.11:54311-107706

在我当前所做的web项目中，采用前后端分离模式前端通过Django 提供restful接口，后端采用微服务架构，微服务之间的调用采用jsonrpc，由于微服务之间的调用很频繁，导致前端得到的响应很慢，所以就不得不做性能优化。 JSON-RPC是一种基于JSON的跨语言远程调用协议。 比xml-rpc、webservice等基于文本的协议传输数据格小； 但是JSON格式的解析开销太大。 GRPC：GRPC是一个高性能、通用的开源RPC框架，由Google主要面向移动应用开发并基于HTTP/2协议（注意是HTTP/2协议，不是我们常使用的HTTP 1_1。HTTP/2协议详细的介绍可以参见官方地址：https://http2.github.io/）标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。为了支持GRPC的跨语言性，GRPC有一套独立存在IDL语言。不过由于GRPC是Google的开源产品，在信息格式封装方面Google主要还是推广的自己的ProtoBuf，所以GPRC是不支持其他信息格式的（至少ProtoBuf效率是大家有目共睹的）。关于GRPC详细的使用介绍，可以参见官方地址： https://github.com/grpc/grpc Thrift：Thrift是Facebook的一个开源项目

对于微服务的实践，一般都是基于Java和Golang的，博主最近研究了下基于Python的微服务实践，现在通过一个简单的服务来分析Python技术栈的微服务实践 技术栈：Python3 + grpc + Zookeeper 服务API：通过学科获取相应的题型 grpc：由Google公司开源的高性能RPC框架，消息协议使用Google自家开源的Protocol Buffers协议机制，传输使用HTTP2.0标准，支持双向流和连接多路复用 Protocol Buffers部分： syntax = " proto3 " ; message Subject { string name = 1 ; } message QuestionType { string name = 1 ; } service SimpleRpcServer { // server streaming rpc // 客户端发送学科，服务端多次返回该学科包含的题型 rpc GetSubjectQuestionTypes (Subject) returns (stream QuestionType) { } } 这里定义grpc的接口类型为服务器流式RPC，即客户端发起一次请求，服务器可以返回多个响应信息，典型的例子有：客户端向服务端发送一个股票代码，服务端就把该股票的实时数据源源不断的返回给客户端：

#1. 前提: 安装前服务器情况,已经安装好了: CUDNN=7.3.0 CUDA=10.0.130 Opencv 2.4.13 相应命令为: cuda 版本 cat /usr/local/cuda/version.txt cudnn 版本 cat /usr/local/cuda/include/cudnn.h | grep CUDNN_MAJOR -A 2 opencv版本 pkg-config opencv --modversion #2. 准备caffe, python环境 从 https://github.com/BVLC/caffe 下载caffe, 用unzip命令解压. python我使用的是Anaconda虚拟环境, 最后附上environment_caffe_27.yml文件, 如果需要可以直接使用下面的命令安装,或者手动安装. conda env create -f environment_caffe_27.yml environment_caffe_27.yml文件内容如下,复制重命名即可: name: caffe_27 channels: - defaults dependencies: - backports=1.0=py27_1 - backports.functools_lru_cache=1.5=py27_1 - backports.shutil

前言: 最近在学习深度学习，最先要解决的当然是开源框架的环境安装了。之前一直在学习谷歌的Tensorflow开源框架，最近实验中需要跟别人的算法比较，下载的别人的代码很多都是Caffe的，所以想着搭建好Caffe环境跑别人的代码。这中间经历过很多弯路，开始是入了Ubuntu16.04的坑，很多教程都说GCC版本不匹配，需要降级，我也尝试过发现很多坑；另外，就是安装matlab版本的Caffe以及安装GPU版本的Caffe，都经历了很多的波折，这前后摸索大概花了半个月左右。最后发现Ubuntu14.04最适合安装Caffe环境。 于是，我想着既然GPU版本或者matlab版本的Caffe环境配置很多坑，为什么不先从最简单的CPU+Python版本开始配置呢？到后面对Caffe框架熟悉了或者有需要用matcaffe的时候，再去摸索GPU或者matlab版本的Caffe配置。这就是我写本博客的初衷，先写个配置Caffe CPU ONLY版本的博客教程，希望初学者不再对caffe环境配置谈虎色变。话不多说，开始我们的教程吧！ 首先，说一下本教程适用的计算机系统环境，本人笔记本安装了Win7+Ubuntu14.04双系统。至于安装双系统，可以参考网上博客：https://www.jianshu.com/p/dfd9436956b9 我下载的Ubuntu14.04是Kyliin版本

1、概述 Mixer是Istio的核心组件，提供了遥测数据收集的功能，能够实时采集服务的请求状态等信息，以达到监控服务状态目的。 1.1 核心功能 •前置检查（Check）：某服务接收并响应外部请求前，先通过Envoy向Mixer（Policy组件）发送Check请求，做一些access检查，同时确认adaptor所需cache字段，供之后Report接口使用； •配额管理（Quota）：通过配额管理机制，处理多请求时发生的资源竞争； •遥测数据上报（Report）：该服务请求处理结束后，将请求相关的日志，监控等数据，通过Envoy上报给Mixer（telemetry） 1.2 示例图 2、代码分析 2.1 Report代码分析 本节主要介绍Report的详细流程（基于Istio release1.0.0版本，commit id为3a136c90）。Report是mixer server的一个接口，供Envoy通过grpc调用。首先，我们从mixer server的启动入口main函数看起： func main() { rootCmd := cmd.GetRootCmd(os.Args[1:], supportedTemplates(), supportedAdapters(), shared.Printf, shared.Fatalf) if err := rootCmd

　　Grpc是googe开发的，是一款语言中立、平台中立、开源的远程过程调用(RPC)系统。新公司的项目服务之间的调用使用的Grpc来实现服务间的调用，这边一开始接到的工作内容是基于Nginx实现Grpc服务端的负载均衡。Nginx的1.13及以上版本是支持grpc的反向代理和负载均衡的。但是公司的nginx服务器的版本是1.10的，所以没办法直接使用grpc的代理。只能使用更底层的tcp层的负载均衡。最终服务跑起来是感觉挺简单的，但是nginx的基础太差，所以过程有点曲折。还是记录下吧。 　　文章分两部分，一个是创建简单的Grpc客户端和服务端的例子（其实也是用的网上的demo，这边就贴一下源码，讲下更细的实现步骤），然后对比下Nginx的Grpc负载均衡和Tcp的负载均衡。 　　一、Java创建Grpc客户端和服务端的例子（创建的配置信息相关的代码基本网上博客的，忘记是哪篇文章了，所以暂时没法给出转载链接。） 　　1、在开发工具ide上创建一个maven project。打包方式选择jar。 　　2、在POM.xml上增加grpc相关的依赖及maven的打包插件 < dependencies > < dependency > < groupId > io.grpc </ groupId > < artifactId > grpc-netty </ artifactId > <

Protobuffer proto3 proto3 比 proto2 新，所以一般选用proto3进行构建项目。 下面英文版可以在 Language Guide (proto3) 上看到。 假设您要定义搜索请求消息格式，其中每个搜索请求都有一个查询字符串。 syntax = "proto3"; message SearchRequest { string query = 1; int32 page_number = 2; // Which page number do we want? int32 result_per_page = 3; // Number of results to return per page. } 该文件的第一行指定您使用的是proto3语法：如果不这样做，协议缓冲区编译器将假定您正在使用proto2。 这必须是文件的第一个非空，非注释行。 指定类型 在上述示例中，所有字段都是标量类型：两个整数（page_number和result_per_page）和一个字符串（查询）。 但是，您也可以为字段指定复合类型，包括枚举和其他消息类型。 分配标签 消息定义中的每个字段都有唯一的编号标签。这些标签用于以消息二进制格式标识字段，并且在使用消息类型后不应更改它们。 请注意，值范围为1到15的标签需要一个字节进行编码，包括标识号和字段的类型

编译程序报错"protoc: Command not found;*** [xxx.pb.go] Error 127"，然后关键字"pb.go"搜到文章<如何在Go中使用Protobuf>，指出需要"1. 安装protoc"和"2. 下载并安装protobuf-go插件"。然后关键字"安装protoc"搜到文章<在 Golang 中使用 Protobuf>，然后依据此标题关键字"go protobuf 安装"搜索到文章<在go语言中安装与使用protobuf的方法详解>，该文章安装protoc十分简洁，但是是2.6版本，安装后编译程序报错`Unrecognized syntax identifier "proto3". This parser only recognizes "proto2".`，只好执行"make uninstall"然后参照关键字"安装protoc"搜到文章<protobuf 3.1.0 安装示例和使用指南说明>，但是到git网址上下了最新的安装，然后编译程序报错"protoc-gen-go: program not found or is not executable;--go_out: protoc-gen-go: Plugin failed with status code 1."，这个就是前面文章中说到的要安装protoc-gen-go。 按照文章<在