问题点
- 快速定位服务故障点比较费劲，是哪个服务的问题，多服务，并且每个服务多个节点集群部署。在我们系统里面，我作为门户，但是后面包着账户中心，支付中心，用户中心等。每次一出现问题，然后都找我们，说是我们的问题，但是大部分情况下都和我们没有关系，但是我们都要协查，就比较费时耗力。我们的做法是：首先我们要比客户早知道问题，定时查询异常单据进行预警，然后发邮件，发企业微信，通知相关人员给予解决，这个确实是一个很蛮不错的东西，不能从根源上把问题解决了，那我们就及时的发现问题。那个是通知到各个系统，还是没有全局关联起来，后来想用一个全局的traceId把业务关联起来，其实就是全链路追踪。需要多个部分大家都参与，结果就是没有做完，如果做完了对于问题定位应该会很快。
- 雪崩效应，可能一个服务不可用了，然后其他依赖该服务的也变得不可用，就像我上面描述的，可以账户呀，你不能提供服务了就是不能了，你怎么容错降级呢，那可是账呀。
- 稳定性下降，服务点多了以后出现故障的几率那肯定是增大的。
- 部署，管理多个节点就比较麻烦了。
- 每个服务都是集群部署，所以这个时候集群下每台机器的定时任务，分布式id的生成问题，分布式锁等都需要考虑
- 集群的容错问题
解决办法
-
监控系统，监控什么内容，中间件内存，网络流量，数据库连接，业务系统里面的某些参数值等等，然后使用一个收集器定时从对应的接口里面获取这个数据，然后提供查询和dashBoard进行查看，同时进行发送邮件通知
-
链路追踪，traceId[一个请求id]，spanId[每个服务节点id]，请求和响应时间，这样可以快速知道是哪里出了问题。
-
日志分析，知道哪里出现了问题后，就去查看日志问题究竟是什么。使用ELK快速的把问题找出来，不过先在容器化后好像有许多别的日志分析框架
-
内部的服务治理，进行动态扩容
-
熔断机制，当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。通过健康检查，直至该服务恢复正常后再重新建立连接。
-
服务降级，把一些非核心业务可以暂时关闭掉，不能影响核心业务流程
-
限流保护，但是目前为止我们的系统还不需要这个，虽然业务上流量也不少，巴不得人家来访问我们呢，还没有到一下打死的地步。
RPC
参考：https://dubbo.apache.org/zh-cn/blog/dubbo-protocol.html
RPC的本质是提供了一种轻量无感知的跨进程通信的方式
通信协议，应用层对于tcp传输数据的接收
应用层协议一般的形式有三种：定长协议、特殊结束符和协议头+payload模式。其实可以参考Netty中不同的解码器，之前看Netty权威指南的时候有一章节专门讲解这个处理。比如FixedLengthFrameDecoder，DelimiterBasedFrameDecoder，LengthFieldBasedFrameDecoder
从网络上以流的形式进行数据的读取，需要确定的是一次有意义的传输内容在读到何时结束，因为一个一个byte传输过来，需要有一个结束。而且数据在网络上的传输，存在粘包和半包的情况，能够应对这个问题的办法就是协议能够准确的识别，当粘包发生时不会多读，当半包发生时会继续读取。
- 定长的协议是指协议内容的长度是固定的，比如协议byte长度是50，当从网络上读取50个byte后，就进行decode解码操作。定长协议在读取或者写入时，效率比较高，因为数据缓存的大小基本都确定了，就好比数组一样，缺陷就是适应性不足，以RPC场景为例，很难估计出定长的长度是多少。
- 够定义一个特殊字符作为每个协议单元结束的标示，就能够以变长的方式进行通信，从而在数据传输和高效之间取得平衡，比如用特殊字符\n。特殊结束符方式的问题是过于简单的思考了协议传输的过程，对于一个协议单元必须要全部读入才能够进行处理，除此之外必须要防止用户传输的数据不能同结束符相同，否则就会出现紊乱。
- 变长协议，会以定长加不定长的部分组成，其中定长的部分需要描述不定长的内容长度。Dubbo 协议实际上就是一种变长协议
分布式ID生成
Leaf「时钟+机器id+递增序列」
Service Mesh
容器化编排
- docker
- k8s
醉卧沙场君莫笑，古来征战几人回？--[凉州词二首·其一]
相关介绍
参考
> 可在下面留言（需要有 GitHub 账号）