yhzhu的随手记

我们知道在Java技术体系中，链路跟踪严重依赖ThreadLocal；因此在多线程的场景下会导致链路跟踪失效.

最近接手了一个新项目，被告知Java代码的gRPC客户端无法访问当前项目中Go代码的gRPC服务。通过问题的排查和部分代码改造个人对gRPC的理解更深入了一层.

技术人员在技术选型的时候如何做好技术与业务的平衡，如何推广技术方案，甚至与产品人员沟通改变某些功能的实现方式，这些问题值得每一个技术人员思考。我们不管采用什么技术方案，最终目的是为了帮助业务发展，使公司在商业上获取回报。如果技术人员能有一些产品和运营的思维，对整个业务的发展会起到更好的效果。

为什么需要调度系统

我们可能有这样的需求:

1. 在某个指定的时间点执行一个任务, 比如凌晨对前一天的数据进行汇总;
2. 在某个操作后的指定时刻执行某一操作，比如：电商下单后一小时没有支付的订单需要被取消;
3. 微服务失败后补偿操作;

「海恩法则」是航空涡轮发动机的发明者帕布斯·海恩提出一个在航空界关于飞行安全的法则。海恩指出：每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。法则强调两点：一是事故的发生是量的积累的结果；二是再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。「海恩法则」虽然针对的是飞行领域，在软件开发领域遭遇生产bug

单体应用依赖比较少，大部分情况我们只需要启动一个应用就可以开始测试工作。架构升级到服务化后，每个应用依赖比较多，任何一个依赖有问题都会影响测试结果；如果服务化环境中多项目并行测试，测试效率会更差 。

目前我们大部分业务都接入了服务化，在过去将近一年的时间里，我们踩了很多坑，也出现了几次生产事故，同时，从某种意义上讲，我们也做了某些「微创新」，使得架构更适合我们团队的实际情况。从目前的结果来看，基本达成了预定目标；

在我们日常生活以及工作中经常会遇到提问题, 我们有没有想过如何提一个好问题？也许有人会说，「提问谁不回？会讲话的小孩子就会问为什么，这有什么值得说的？」没错，从这个角度上说机会每个人都会提问。但是，我们有没有想过，我们问问题的目的是什么？是得到对问题的解答。大家有没有遇到过这样的情况，自己问题发给对方后始终得不到回复，或者对方敷衍了事，更有甚者被对方怼回去。如果遇到这些情况，我们应该好好反思一下，我们是不是提了一个好问题；在说好问题之前结合个人的经历谈谈什么样的问题不是一个好问题。

前几天核心基础服务(简称S,两节点)发生了一次线上故障，导致整个基础服务雪崩，最终，该基础服务故障导致整站多项功能失效；

服务化的过程中必然会面对服务拆分的问题；拆分粒度太粗不能体现服务化的优势，拆分过细会导致各项成本过高；所以架构师在服务拆分时要权衡各方面的利弊根据当前情况做出最优解;以下内容是我们团队在使用dubbo的过程，根据实际情况考虑的服务拆分方式；