问题

在Spring Cloud项目中，前后端分离目前很常见，在调试时，会遇到两种情况的跨域：

1. 前端页面通过不同域名或IP访问微服务的后台，例如前端人员会在本地起HttpServer 直连后台开发本地起的服务，此时，如果不加任何配置，前端页面的请求会被浏览器跨域限制拦截，所以，业务服务常常会添加如下代码设置全局跨域：

什么是SkyWalking?

SkyWalking 是观察性分析平台和应用性能管理系统（APM, Application Performance Management)，由个人开发者 吴晟 于2015年开源，2017年加入Apache孵化器。

它提供分布式跟踪、服务网格遥测分析、度量聚合和可视化的功能，支持Java、.Net、PHP、NodeJs、Golang、LUA语言探针，以及Envoy+Istio构建的Service Mesh，支持OpenTracing规范。

核心API

在使用Akka kafka consumer前， 先了解下几个核心API：

• ConsumerSetting Consumer的配置信息；
• ConsumerRecord Kafka消息的封装类，包含消息的K、V，以及该消息所属的topic, partition, offset, timestamp等；
• ConsumerMessage 是ConsumerRecord的进一步充血模型，提供了自动commit以及修改offset信息的API；
• Subscription 该Consumer的订阅信息，有AutoSubscription和ManualSubscription两个子接口，分别用于自动从Topic读取Partition以及手动绑定Partition；

Akka Stream

在用Akka去对接Kafka之前，有必要先简单了解下Akka Stream，它是基于Reactive Stream(Akka是其创立成员之一)的。Akka Stream中，将流的拓扑处理逻辑命名为Graph，拓扑中每个操作命名为Operator。
它将流式处理抽象为几个核心API：

• Source : 有且仅有一个Output的operator，对应数据的来源，将数据反序列化后发送给下游逻辑。
• Sink : 有且仅有一个Input的operator，对应最终数据的去向，常用于结果存储。
• Flow : 有且仅有一个Input和Output的operator，用于定义数据的处理逻辑。
• RunnableGraph : 一个对接了Source和Sink，并且已经准备好run()的Flow。一般用source.to(sink)或source.runWith(sink, materializer)构成一个RunnableGraph，可通过via(flow)添加其他flow。
• Materializer : 这个SPI(Service Provider Interface)是根据前面定义的graph进行资源申请，生成相应Actor类，然后进行执行的。这篇博文从源码级对它的原理进行了阐述，写的相当透彻，就不再重复了。

在使用路由功能之前，我们需要先了解下常规概念：

• Router 路由器，消息由外部发送到路由器，再由路由器通过路由算法转发给具体的执行者，相当于消息的中转站。
• Routee 路由目标，最早处理消息的地方。

在Akka中，提供了两种做路由的方式：

前面一个章节akka cluster管理介绍了Akka Cluster的底层原理，这一章就来看看如何使用。

集群后台接入

对外

在前面remote actor一章提到过，akka remoting是Peer-to-Peer的，所以基于remote功能的cluster是一个去中心化的分布式集群。

Akka Cluster将多个JVM连接整合在一起，实现消息地址的透明化和统一化使用管理，集成一体化的消息驱动系统。最终目的是将一个大型程序分割成若干子程序，部署到很多JVM上去实现程序的分布式并行运算（单机也可以起很多节点构成集群）。更重要的是, Akka Cluster集群构建与Actor编程没有直接的联系，集群构建是在ActorSystem层面上，实现了Actor消息地址的透明化，无需考虑目标运行环节是否分布式，可以按照正常的Actor编程模式进行开发。

我们知道，分布式集群是由若干节点组成的，那么节点的发现及状态管理是分布式系统一个比较重要的任务。Akka Cluster中将节点的生命周期划分为：

背景

Gossip protocol 也叫 Epidemic Protocol （流行病协议），实际上它还有很多别名，比如：“流言算法”、“疫情传播算法”等。

这个协议的作用就像其名字表示的意思一样，非常容易理解，它的方式其实在我们日常生活中也很常见，比如电脑病毒的传播，森林大火，细胞扩散等等。

研究Akka过程中，发现Akka的node间是Peer-to-Peer的，就意味着任何一个节点都能处理来自外部请求，那就存在一个一致性的问题，即如果集群中两个节点间的通讯断了，但是又都能对外提供服务，这时各自在接受请求造成的状态变化应该如何解决？Akka采用的是Vector Clocks来解决一致性的。这个算法常见于分布式存储上，对于EBA也很常见，所以如果要搞EventSourcing，这个知识可能会被用到。在研究Vector Clocks时发现两篇好文，本文是其中之一，讲的非常白话清晰，算是先讲算法基础概念，后一篇是直接讲算法实现了。另一篇讲简单实现的我就不转了，有兴趣的直接猛击这里跳转。

physical clock

机器上的物理时钟，不同的机器在同一个时间点取到的physical clock不一样，之间会存在一定的误差，NTP可以用来控制这个误差，机器之间的时钟误差可以控制在几十ms以内。两个事件a和b，a在机器M1上physical clock为12点5分0秒6ms发生，b在机器M2上physical clock为12点5分0秒7ms发生，这并不代表a发生在b之前，因为两个机器上取到的physical clock和真实时间(这个时间就是国际标准时间UTC，可以通过原子钟，internet，卫星获得)之间都有误差。比如机器M1的physical clock比真实时间慢10ms，那么事件a实际上是在真实时间12点5分0秒16ms发生的，机器M2的physical clock比真实事件慢5ms，那么事件b的实际上是在真实时间12点5分0秒12ms发生的，显然，事件a发生在事件b之后。

起因

原文收录在我的 GitHub博客 (https://github.com/jawil/blog) ，喜欢的可以关注最新动态，大家一起多交流学习，共同进步，以学习者的身份写博客，记录点滴。

最近在学习Node.js里面的fs模块，遇到了一个比较诡异的现象，踩到了坑，就是读取当前目录下的一个文件，死活读取不到，由于之前对于Node.js里面的path模块也不太熟悉，也没系统研究过，所以今天就踩了这个坑，记录踩坑的过程，防止以后踩坑和大家也踩坑。