yhzhu的随手记

为什么需要调度系统

我们可能有这样的需求:

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

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

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

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

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

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

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

需求缘由

最近部分只读服务已经切换到了Dubbo提供的服务化接口；经过一段时间的生产验证, 各种监控指标显示非常稳定，所以打算开始切换写服务接口; 但大家对写操作跑服务化没有信心，于是提了一个需求能随时将远程rpc调用切换打本地jar方法调用；

在决定进行服务化时，我们做了一些必要的准备工作；从服务治理，链路跟踪，监控以及报警方面到代码层面，运维，流程等多个方面做了相应的调整

在分布式系统中，同时满足“CAP定律”中的“一致性”、“可用性”和“分区容错性”三者是不可能的。在互联网领域的绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。