Istio 现在是 Service Mesh 中最火热的项目了，它主要负责对服务网格中的流量进行管理，包括动态服务发现、服务路由、弹性功能等。它作为 Service Mesh 的控制平面，配合 Envoy 作为数据平面，构成了 Service Mesh 中流量管理体系。

我们来说说 kubernetes 的服务发现。那么首先这个大前提是同主机通信以及跨主机通信都是 ok 的，即同一 kubernetes 集群中各个 pod 都是互通的。这点是由更底层的方案实现，包括 docker0/CNI 网桥、flannel vxlan/host-gw 模式等，在此篇就不展开讲了。

我们可以使用 zookeeper 作为注册中心来实现服务的注册与发现，curator 框架提供了 curator-x-discovery 扩展实现了开箱即用的服务注册发现，但更多时候我们还是选择自己去实现，那这个时候我们需要额外关注 zookeeper 的 1 个特性，即 wathcer。

在微服务的应用场景下，服务之间可以通过各种方式与协议进行交互，同时整条链路也会变得比较长。与此同时，我们会希望一些数据在整条链路中进行透传，比如说用作对普通 api 参数的动态补充、链路压测标识或者灰度发布标识等。

最近在做类隔离相关的一些工作，而恰恰之前协助开发同学时也发现会遇到许多类加载相关的异常，并且往往比较难定位与解决。这里简单做一个小总结。

线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。

9月26日，在杭州云栖大会上各位专家分享了关于互联网中间件的一些内容。

我司目前 RPC 框架是基于 Java Rest 的方式开发的，形式上可以参考 SpringCloud Feign 的实现。Rest 风格随着微服务的架构兴起，Spring MVC 几乎成为了 Rest 开发的规范，同时对于 Spring 的使用者门槛也比较低。

近来总是会有服务遇到 OOM 的情况，简单定位后发现 rpc 框架内存占用较多，看来是时候需要优化一波了。

在去年写过一篇关于微服务优雅上下线的文章，比较笼统的将了一下微服务保证优雅上下线的一些方式。但随着应用的逐渐 k8s 化，原有的微服务下线会存在一些问题。

当一个单体应用改造成多个微服务之后，在请求调用过程中往往会出现更多的问题，通信过程中的每一个环节都可能出现问题。而在出现问题之后，如果不加处理，还会出现链式反应导致服务雪崩。服务治理功能就是用来处理此类问题的。我们将从微服务的三个角色:注册中心、服务消费者以及服务提供者一一说起。

在我们对微服务架构有了整体的认识，并且具备了服务化的前提后，一个完整的微服务请求需要涉及到哪些内容呢？这其中包括了微服务框架所具备的三个基本功能。

抛去教条性质的解释，从巨石应用到微服务应用，耦合度是其中最大的变化。或是将多个模块中重复的部分进行拆分，或是纯粹为了拆分膨胀的单体应用，这些拆分出来的部分独立成一个服务单独部署与维护，便是微服务了。

SOFAMosn是基于Go开发的sidecar，用于service mesh中的数据面代理。

经常做线上问题排查的可能会有感受，由于日志打印一般是无序的，多线程下想要串行拿到一次请求中的相关日志简直是大海捞针。那么MDC是一种很好的解决办法。

经常会遇到需要处理http请求以及响应body的场景。而这里比较大的一个问题是servlet的requestBody或responseBody流一旦被读取了。就无法二次读取了。针对这个问题，spring本身提供了解决方案，即ContentCachingRequestWrapper/ContentCachingResponseWrapper。

很多人都会在平时开发过程中遇到400或500异常，并且也没有走到服务端controller中，就变得有些不知所措。

在实际生产环境中，全链路跟踪框架如果对每个请求都开启跟踪，必然会对系统的性能带来一定的压力。与此同时，庞大的数据量也会占用大量的存储资源，使用全量采样的场景很有限，大部分应用接入链路跟踪的初衷是错误异常分析或者样本查看。

作为应对高并发的手段之一，限流并不是一个新鲜的话题了。从Guava的Ratelimiter到Hystrix，以及Sentinel都可作为限流的工具。

在全链路跟踪框架中，Trace信息的传递功能是基于ThreadLocal的。但实际业务中可能会使用异步调用，这样就会丢失Trace信息，破坏了链路的完整性。