1.总体概述1.1.根据实现方式分类微服务1.0：用库的形式在微服务应用程序中导入使用。基于nginx，kong等微服务2.0：用代理的方式为应用服务提供能力-服务网格（Service mesh）用直接代理的方式, Linkerd1.0sidecar的形式运行，基于k8s istio1.2.服务网格-service mesh服务网格（Service mesh）是用于处理服务间通信的专用基础设施层。

一、前言k8s对Pods之间如何进行组网通信提出了要求，k8s对集群的网络有以下要求：所有的Pods之间可以在不使用NAT网络地址转换的情况下相互通信所有的Nodes之间可以在不使用NAT网络地址转换的情况下相互通信每个Pod自己看到的自己的ip和其他Pod看到的一致k8s网络模型设计基础原则:每个Pod都拥有一个独立的 IP地址，而且 假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中

目录背景分析原因总结背景早先的都采用基于grpc+etcd做服务注册和服务发现，都是正常的后来有部分服务采用k8s部署，为了新旧兼容，服务会按照老方式把宿主机的ip注册到etcd上，k8s体系类使用体系类的服务发现，k8s体系外的依然使用原来的方式，互不影响但是有服务基于k8s部署之后，发现client调用接口超时，而直接通过ip调用却是正常且多数是发生在...

grpc源码注解(通过阅读源码的一些理解)最近在看grpc的源码（基于golang），为了方便自己阅读以及理解，增加了一些注解。这里分享出来，希望对大家有些帮助，也是督促自己啦地址：https://github.com/liangzhiyang/annotate-grpc-go目前client端基本流程都ok了（还有server端等等）会持续更新~~接

轻松筹是全国1.6亿人使用的全民众筹平台，几乎所有核心业务都依赖于账号系统，账号系统的用户体验，安全性，稳定性直接影响着轻松筹所有业务的运行；轻松筹的发展非常迅速，已经展开了多条产品线，单点登录的需求愈加强烈；另外由于历史包袱的原因，也遗留了一些问题亟待解决。本次交流主要与大家分享一下轻松筹账号系统(侧重登录授权服务)的架构设计和改造方案。历史背景：由于历史包袱的遗留问题，轻松筹的账号...

背景当并发请求高的时候会出现connection reset by peer 这样的错误，也就是 服务端主动关闭了socket但是客户端依然再用分析正常的tcp 建立连接的时候tcp connect 请求进来的时候 服务端 会加入 SYN队列当三次握手成功之后，会从 SYN队列移动到ACCEPT队列然后应用层通过accept 方法接受新的socket结论...

最近遇到 grpc 客户端报错rpc error: code = Unavailable desc = transport is closing，原因是连接长时间没有使用，被服务端断开，但是看过grpc源码的都知道，如果failfast 设置为false的话，应该会重试的；并且 连接关闭之后grpc.clientConn也会维护这个状态，所以不应该出现这个问题才对，这个是个很奇怪的事情...