c++ 前向声明(forward declaration)

Posted by 夏泽民

前向声明的定义:有些时候我们可以声明一些类但是并不去定义它,当然这个类的作用也很有限了。



Thrift 源码

Posted by 夏泽民

Thrift之代码生成器Compiler这个功能是一个单独的工具程序,它会独立的生成一个可执行文件。 第一节 类关系图 类关系图如下所示: 注意:实线代表继承关系;而虚线代表依赖关系。



thrift annotation

Posted by 夏泽民

1,作为注释(desc=”errno”) 2,在 thrift idl 语法的基础上, 加入一些扩展的 annotation 字段, 用于指导生成 http 以及 thrift 下游服务的 sdk 3,根据不同语言加上不同的前缀来做区分, 比如 go.type, go.filed_name 等. 4,Go语言特有语法 不支持无符号标量类型,如uint64 字段类型codegen和字段标识关系: require:对于标量类型,codegen代码为标量类型json注解没有omitempty optional:对于标量类型,codegen代码为指针类型,json注解有omitemtpy 结构体 require和optional结构体都是指针类型、包含omitempty slice、map require和optional结构体都是非指针类型、包含omitempty。如果元素是struct,则struct不能是指针。 Golang内置了对RPC支持,但只能适用于go语言程序之间调用,且貌似序列化、反序列化性能不高。如果go语言能使用Thrift开发,那么就如虎添翼了。可惜,thrift虽然很早就包含了golang的代码,但一直都存在各种问题无法正确执行,以至于GitHub上有许多大牛小牛自行实现的Thrift代码



Dapper

Posted by 夏泽民

http://bigbully.github.io/Dapper-translation/ http://static.googleusercontent.com/media/research.google.com/zh-CN//archive/papers/dapper-2010-1.pdf https://github.com/TaXueWWL/lite-tracer https://www.ibm.com/developerworks/cn/web/wa-distributed-systems-request-tracing/index.html https://zipkin.io/ https://github.com/openzipkin/zipkin https://github.com/naver/pinpoint 基于HTTP同步调用,能实现TraceId的传递,SpanId的生成及传递,ParentSpanId的获取。 应用层无感知,业务请求无需显示传递链路信息。 由于我们是在应用层协议传递TraceId、SpanId、parentSpanId,则Http头是传递参数的最佳位置。这里只进行HTTP协议层的传递,如果要进一步 实现在RPC协议中的传递,我们就需要在RPC的序列化协议中增加定制化字段,将TraceId、SpanId传递下去 对于ParentSpanId而言,首次请求的时候,父Span不存在,因此默认为-1,后续进行分析的时候只要遇到某个Trace节点的父Span为-1,则表示这个请求 是首次请求,也就是Dapper论文中提到的Trace树形结构中的根节点。 对于每个 Trace 树,Trace 都要定义一个全局唯一的 Trace ID,在这个跟踪中的所有 Span 都将获取到这个 Trace ID。 每个 Span 都有一个 Parent Span ID 和它自己的 Span ID。 追踪系统中用 Span 来表示一个服务调用的开始和结束时间,也就是时间区间。追踪系统记录了 Span 的名称以及每个 Span ID 的 Parent Span ID,如果一个 Span 没有 Parent Span ID 则被称为 Root Span,当前节点的 Parent Span ID 即为调用链路上游的 Span ID,所有的 Span 都挂在一个特定的追踪上,共用一个 Trace ID。



Istio

Posted by 夏泽民

https://github.com/istio/istio https://www.servicemesher.com/blog/back-to-microservices-with-istio-p1/ 在微服务架构中,服务可能会用不同的语言实现并部署在多个节点或集群上,具有不同的响应时间或故障率。如果服务成功(并且及时地)响应了请求,那么它的性能就算是令人满意的。但现实情况并非如此,下游客户端应该在上游服务过于缓慢时受到保护。反之,上游服务也必须被保护,以免被积压的请求拖垮。在多客户端下情况会更加复杂,并可能导致整个基础设施出现一系列的连锁故障。这一问题的解决方案是采用经过时间检验的熔断器模式。



Search

Popular posts

Anything in here will be replaced on browsers that support the canvas element

Recent posts

This blog is maintained by 夏泽民

Get in touch with me at 465474307@qq.com

Subscribe to our mailing list

* indicates required