之前从国外的一篇博客上了解到了ServiceMesh，觉得很感兴趣，感觉它是完全就是为分布式量身定做的以后肯定会大火，不管以后能不能进入运用ServiceMesh思想的公司，先了解是不错的，果不其然，阿里系首先就来了个dubbo mesh和sofa mesh，我参加阿里的dubbo meeting up时，宣布发布了dubbo mesh。以下内容做个这段时间的学习记录。

Service mesh 我理解其实不是新技术是一个新技术理念。

看了很多相关的文章也看了某些案例，准备动手实践一下。很多service mesh的文章和案例通常都会提到两个单词，data-plane和control-plane，即数据面板和控制面板。

顾名思义，我理解数据面主要是负责服务间通信传递信息的相关操作，比如负载均衡、服务发现、心跳检测、路由、监控等等，但是你会发现，如果只有数据面板其实是没用的，因为数据面板功能再多但是它是死的，他就像一台计算机，软硬件都配好了就算你跟他通上电，插好网线他也不能工作，因为它不知道他要做什么和怎么做。

而控制面板恰好就是做这个事的，它告诉控制面板应该做什么怎么做，比如服务间通信的规范、路由的地址以及路由的规则、监控的指标、限流、熔断的机制是什么配置是什么？控制面板才能真正让数据面板变成一套可运行的系统。

其实通过很多案例知道，很多大中型的公司特别是互联网公司，他们很早以前就有了自己的数据面板可能叫代理更合适，因为那时候还没流行service mesh的概念，他们也有控制面板（可能那时候更明确的叫法是库或者配置中心）。所以service mesh只是概念新，但应用应该很早就有了，只是现在的提出的service mesh应该更激进一些，直接把数据面板和控制面板剥离出来作为基础设施，脱离业务。

由于近年云原生、容器、微服务等概念的火热，微服务的落地案例越来越多，带来技术革新的同时也带来了烦恼。即微服务的运维（服务治理、路由策略、性能监控等）复杂度，不管是云原生还是容器都旨在让微服务能更快速更高效的部署，但是服务部署后是需要运行的，这么多服务之间的运行的有效性谁来保证，当然在云原生等概念火热之前，很多公司都有自己的微服务架构，服务之间运维也都有自己的一套。但是很多方案基本上都是把对服务运维的管理的代码或者说库耦合在业务代码里的，比如zk的使用，就是耦合在业务代码中的，而且很多时候是每种编程语言都需要开发一套代码来支持。这就让运维变得越来越繁琐，Dev和Ops耦合程度会越来越高。

现在的Istio、linkerd、sofa mesh等其实就为了解决上面说到的痛点。那怎么解决呢，就是把属于基础设施的组件，属于ops的工作从业务中剥离出来。在业务服务的身边跟他派一个书童，这个书童就是service mesh的应用。书童存在的价值是什么？就是让他的少爷能专心的读书，除了读书其它事情一概不用管。我理解这就是service mesh真正的价值。

关键词解释

云原生（cloud native）
我理解的是什么都在云上做，存储、交付、部署、测试等等，最大的特点就是快。

源引：

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

最近关注ServerMesh时，又听到一个Serverless，所以又了解了解，做个笔记吧。

最近google开源了Knative，感觉Serverless可能又要起飞了。

Serverless也是一种架构模式，中文意思是“无服务器”架构。目前，业界并没有给出明确的定义，把其分成两种类型，分别为“Backend as a Service” 和 “Functions as a Service”。

个人理解就是开发是不需要维护基础设施以及基础组件，直接填业务代码。

Serverless与传统架构比较

传统的互联网APP主要采用C/S架构，服务器端需长期维持业务进程来处理客户端请求，并调用代码逻辑完成请求响应流程。而在Serverless架构中，应用业务逻辑将基于FAAS架构形成独立为多个相互独立功能组件，并以API服务的形式向外提供服务；同时，不同功能组件间的逻辑组织代码将存储在Amazon Lambda，Azure Function，Google Cloud Functions等产品上，业务代码仅在调用时才激活运行，当响应结束占用资源便会释放。

个人理解类似事件驱动的感觉，来了请求就触发业务代码。我理解这种形式是不是很有可能比传统的长期维持的方式要慢一些，因为传统是等着你时刻准备着，serverless是你来了我再启用。

Serverless 如果是在高并发而且要求数据安全性、独立性的场景应该是不适用。和云厂商真的是强耦合了。后续有时间继续学习吧。

如果想试一试，可以去Cloudflare](https://workers.cloudflare.com/docs)试试跑一个简单的js脚本感受一下。

参考：

这段时间区块链很火，虽然我没用什么兴趣去做区块链，因为愚笨的我现在还没太看懂区块链到底能进入哪些行业？就像之前看红杉资本的一位VC的访谈，她的成功秘诀之一就是，自己没看懂的行业是肯定不会投的不管它多么火。

但是虽然这么说，我还是得了解一下到底是个什么玩意？虽然网上到处是文章但是都是东拼西凑得，不太体系。所以当我听说caoz大佬要开个区块链的扫盲视频，所以马上付费了解了下同时也看了下MacTalk大佬写的文章….。以下是这段时间对于区块链的一些笔记。

从图中可以看出，现目前区块链的应用主要有两种场景，公有链和联盟链，其实还有私有链

所以首先要了解比特币不是区块链，区块链是一种技术集合的统称，比特币等是区块链的一种应用。

区块链的核心概念：

• 去中心化

  我理解就是P2P，没有集权，数据分布式存储，交易变得平等、透明、公开。这是美好的理想。

• 共识机制（公共账本）

  就是解决信任问题，区块链要求每个联结点在共同的账本上对每一笔交易进行分布式记账。所以每个节点都对账本负责。

• 加密

  通常是非对称加密，用于个人的账户交易。

• 算法

  各种算法，比如分布式一致性算法，加密算法等，作为交易的支撑

• 激励机制（针对发币的场景）

  发币，也可通过挖矿来挣币，没有甜头谁帮你干活，本质就是P2P

其实说白了 感觉就是一堆人在维护一个账本，这个账本每人都有一份，而且还都一模一样。

当然现在很多企业应用区块链，也就是联盟链，很多时候还是利用区块链的理念，在一些环节做到公开透明从而减少成本，提升效率。联盟链是指一些愿意彼此实现共信的机构和组织共同组建的，为各自机构提供共识信用和价值传递的平台，这样只要联盟不存在一家独大的情况，还是可以实现共识基础。

区块链我觉得应该还是一个风口，虽然不如人工智能大风大浪，但是有风有浪是肯定，抓紧时间补补吧。总比啥都不知道要强,另外我始终觉得去中心化，共识机制等强调的公平、透明只是美好的愿望。决定权始终是掌握在部分人手里的，不然为毛这么多人买矿机其实不就是增加自己的权重么。还可能存在算法劫持。所以只是美好的。所以不懂又想乘机赚一笔的就别上了，只能成为韭菜。

名词解释：

POW

• 共识算法其实分很多种，目前最常提到的，比特币和以太坊所用到的，是叫做POW的共识算法，基于工作量证明的一种信息保障的算法。

区块链怎么工作的，pow为例。首先，每条交易，记账信息，是一条记录，每条记录都会发布到各个不同的节点，节点将检查最新的记录打包到一个新的区块上，然后通过算力证明，将区块发布到网络。但这里的算力证明其实是有极大的偶然性随机性，也就是有非常多的矿机，现状可能是几十万台同时打包和发布数据，但只有一个幸运的矿机，获得了证明，生成了新的区块，并获得了区块的奖励。

当这个区块发布后，其他的节点会很快得到这个信息，然后放弃掉当前已经打完包的数据，开始接受新的数据，进行下一步数据打包，并试图证明算力获得发布权力和区块奖励。所以你会发现其中的空耗是很严重的这就不难解释为什么有那么多矿机但是获得比特币还是特别难特别少。但也正是因为所有节点的概率一致，保证了任意节点被入侵，被篡改，其数据信息，不会被其他节点接受，也就是保障了主链的安全性。

POW目前的局限是出块速度被限定了，比特币差不多10分钟出一个区块，所有交易均需要记录在区块内，所以这样也就限制了交易频率，由于一个区块只有1M，可以承载的交易信息是有限的，所以目前比特币的交易频次被限定在非常低的量级上，差不多一秒才可以支撑不到10个交易。

POS

POS共识算法，也就是基于拥有的数量和时间获得证明的算法。简单解读类似于存本取息，你在系统中存的钱越多，存的时间越长，你所获得的收益就越多，这样算力竞争的意义被弱化，而拥有的意义被强化。

DPOS

在POS之上又有人提出了DPOS，在基于拥有数量的基础上，投票选举工作节点的模式，由投票委任的节点负责运算打包，一旦出现坏区块或者故障，会有一套机制保障自动切换到其他节点，实现平滑过渡

智能合约

来源于以太坊。智能合约，也就是说，在区块中传递的合约，或者说传递的字符串，不是单纯的字符串和信息，而是一段可执行的脚本，比如说，有触发条件，有交互能力。

图灵完备

图灵完备，什么是图灵完备，就是说不考虑硬件限制的情况下，这个脚本的支持性可以满足所有图灵机的功能诉求，图灵机也可以简单理解为全功能计算机。

以太坊

以太坊是一种虚拟货币，这个定义是错的，以太坊是一个平台，上面跑了几千种虚拟货币，其中之一是以太坊自身的代币。而这个平台不但可以发布货币，还可以发布应用，智能合约的应用，这个想象力是蛮大的。

硬分叉

说一下硬分叉，刚才也提到了比特币的第一次硬分叉，所谓硬分叉，是分叉方约定，在某个区块节点开始，启用新的系统架构继续前进，不再和主链保持一致，但同时也继承了该节点之前的所有区块。在这个节点之后，双方各自挖各自的矿，各自爆各自的块，各自走各自的路。

ICO

ICO 是一种基于区块链进行资金筹集的方式，目前市场上的ICO主要分两种类型，一种是股权众筹，一种是代币发行。

从股权众筹来说，ICO虽然通过代码来保障发行规模和你所拥有的比例，也就是说这个你所拥有的部分是不会被篡改，不会被恶意侵吞的，听上去很合理是不是？但问题在于，没有任何一个国家的法规和政策，规定或约束了企业股权与虚拟代币之间的关联，你说你不相信政府，你要去中心化，那么太多人没有意识到，去中心化同时也意味着失去权力机构的保护和制约。发行的代码是算法约束的，但与企业的发展关系，是靠人性约束的，算法是约束不了人性的。

代币模式

另一种代币模式，就是发行的是某个应用场景或平台中的代币，而不是股权，这个代币可以在这个平台中使用，并通过区块链技术保证这个代币的发行是可控的，可信任的。

区块链的商业生态，ICO是非常大的一块，目前也是势头最火的一块，但我个人认为目前问题很大，过于挑战人性，我是非常拒绝现在那些ICO行为的。此外硬分叉，虽然最开始我们说硬分叉有其技术争论的原因；但后来就变味了，借用硬分叉的名义薅韭菜，这里信息不对称因素太大，很多人入场的人根本不知道分叉币的流通盘有多低，不知道一旦大交易所或钱包系统派糖后价格会雪崩下跌。

参考：

参考：

早上地铁上啃kindle里的万万没想到，里面有个小结讲的是穷人和富人的人脉结构。为什么穷人加粗，因为我就是穷人。

里面有两个词语我比较深刻，强联系 弱联系。

所谓强联系其实就是讲的是平时跟你比较近的人，当然反之平时不怎么联系甚至没见过面的则为弱联系。通常我们都愿意跟强联系的人一起做事，因为熟。但是文章里面讲到外国友人做了几个相关的实验，恰恰证明其实真正能帮到你的很多时候是弱联系的人。因为他们有个共同的特点就是不在你当前的社交圈内。这一点很重要，因为强联系的人经常混在一起，你们的想法或者做的事都差不多，所以发现不了什么新的东西。然而弱联系的意义就是把不同的社交圈子连接在一起，从圈外跟你提供有用的信息。所以人脉的关键不在于你融入了哪个圈子，而在于你能接触多少圈外的人。后面还讲了其它几个实验，得出的结论就是，虽然咱们都重视强联系，但是人们的大部分知识还是来源于弱联系。其实很好理解，因为强联系的人愿意跟我们交流我们也经常交流，话多了当然就没什么新意了。

还有个观点，文章是单独拿出来说的，就是别跟熟人合伙。这个其实对中国人来说尤其困难，包括我，里面说到的一点我是很认同的就是创新能力，跟熟人搭伙，创新能力肯定是没有跟弱联系搭伙强的。熟了很多东西反而有限制。

文章实验指出，富人越容易跟不同阶层和不同地区的人联络，而且阶层多样性比地区多样性更重要。虽然富人爱跟各种人联系，但是真正说话的时间比穷人的短。所以知道了吧，要致富先得学会别强依赖，强联系的亲朋好友，得学会接触新的圈子。其实就是信息的传递，通过弱联系，有用的有启发的肯定会比强联系的多，你想想，强联系的才几个人，弱联系的又有多少，就算按比例弱联系也是完胜嘛。

一天看冯大的文章，里面有个词语叫 本位主义，知识渊博的我，不得不去百度一下，看看到底啥意思。然后竟然有意外收获，还找到了其它两个主义，感觉挺有用的，做个记录，告诫自己！

三大主义分别为：

• 本位主义
• 老大主义
• 怨职主义

本位主义

指在处理单位与部门、整体与部分之间的关系时只顾自己，而不顾整体利益，对别部、别地、别人漠不关心的思想作风或行为态度和心理状态。

这种主义是我见过最多的，基本上呆过的公司都存在这种人才，营销尤盛。这种人其实我是很不喜欢的，因为我太无私了，哈哈！没有其实我也顾自己，但是我不只顾自己，我是正儿八经的为大家放弃小家的那种革命人士，只要公司或者领导没有对我不仁我绝对是把公司、领导的利益放在我前面的。好了夸了自己半天，说回正题。本位主义的人他们有个优势，就是通常他们的kpi都是比较不错的，至于原因你想想kpi的重点不就是考核个人么，只为个人，能不kpi好么。幸好我做的是技术岗，通常这类人很少在身边。

老大主义

老大主义为特权主义、目中无人、不知天高地厚，总感觉自己现在已经是天下第一，殊不知天外有天人外有人。

这类人 是我敬仰的一批人，对他们来说没有所谓的雨天，能装逼天天是晴天。这种人也遇到过，国企尤盛，之前在国企待过一段时间，天天看他们装逼，是在看不下去然后就走了。有两把刷子你在装逼呗。千万不能成为这种人，幸好我看了看镜子中的自己，没有这份潜力，我就安心了。主要是太低调。

怨职主义

怨职主义就是公司某些员工天天抱怨公司不好、产品不好、待遇不好，整天怨天尤人，总认为自己的这份工作干不干无所谓，从不考虑自己是否对这份工作做专、做精、做透、做熟的一种现象。

这类人应该是比较普遍，我也偶有这样的情绪，因为总避免不了遇见傻逼，当然也可能是我看你是傻逼，你看我也是傻逼。我一度自己思考过为什么会抱怨，后来总结了一下主要是两点，一点是不公，另一点是遇见了傻逼队友。现在的我很少抱怨了，因为我发现首先不公是到处存在的，要想天平往你这边倾一点那你就创造更大的价值，说起来俗，但最后其实就是看这个。另一个你不能避免遇到傻逼队友，你知道吧，生活就是这样，哪来一帆风顺，你想想西游记没了猪八戒，你能想象么。而且一个人负能量不能太多，多了容易长皱纹。

要以此为戒，做一个三无主义的好青年。

定义参考：

事业部老大从17年开始就在推OKR，以前都是说KPI，所以我想知道OKR又是个啥，以此文章做个记录。

什么是OKR体系？

OKR体系的全称是Objectives & Key Results，即目标与关键成果。所谓OKR，O = Objective 可以理解为企业目标，KR ＝Key Results 可以理解为关键成果。浓缩在一起就是“为确保达成企业目标的关键成果分解与实施”。

二、OKR与KPI的区别

如果要说 OKR 和 KPI 的区别，区别就在于 KPI 只能让驴使劲走，而 OKR 用于保证驴头朝正确的方向，有些驴拼命想往前走，不希望落后于别人，这时候 OKR 用于帮助驴少走曲线。

OKR考核：“我要做的事”，KPI考核：“要我做的事”，理解不同，但二者都强调有目标,同时也需要有执行力。OKR的思路是先制定目标，然后明确目标的结果，再对结果进行量化，最后考核完成情况。KPI 的思路也是先确定组织目标，然后对组织目标进行分解直到个人目标，然后对个人目标进行量化

解释来源于：

第一次接触dubbo好像是在14年吧，13年参加工作时，在一家半国企，当时他们用的是axis2，当时那一堆代码+XML，让我怀疑是否应该继续干IT，觉得太难用了。后来接触了dubbo，觉得这玩意好，省了很多事，感概开源的力量和大公司的体量。用起来真实很通畅。

当然我们公司也没有作妖，非要选个与众不同所以还是选了dubbo作为服务之间的通信框架。

我这儿也不做什么源码解析了，比我专业的细致的网上很多，我主要解析一下我在用dubbo过程中遇到的问题相关的源码。比如今天讲的就是dubbo的异常机制、序列化协议hession相关的源码。

问题起因在于我们系统中定义了自己的一套异常处理机制，有个自定义异常

图中的ApiException是我们定义的针对接口异常的异常类，长成下图这样。

红框的部分是这次发生问题之后加的一个构造参数，加完之后就搞定了。那为什么呢？我们跟着异常信息我们知道是dubbo用的hession那块反序列化报了异常，跟下源码看下。

• 我们找到JavaDeserializer的instantiate方法，找到_constructor，发现是个Constructor，找到赋值地方，在JavaDeserializer实例化时赋值，进入JavaDeserializer构造方法，根据赋值代码，并且因为我们的ApiException是不知一个构造函数的所以_constructor肯定不会为null,所以

    public JavaDeserializer(Class cl) {
    	this._type = cl;
        this._fieldMap = this.getFieldMap(cl);
        this._readResolve = this.getReadResolve(cl);
        if (this._readResolve != null) {
            this._readResolve.setAccessible(true);
        }

        Constructor[] constructors = cl.getDeclaredConstructors();
        long bestCost = 9223372036854775807L;

        for(int i = 0; i < constructors.length; ++i) {
            Class[] param = constructors[i].getParameterTypes();
            long cost = 0L;

            for(int j = 0; j < param.length; ++j) {
                cost = 4L * cost;
                if (Object.class.equals(param[j])) {
                    ++cost;
                } else if (String.class.equals(param[j])) {
                    cost += 2L;
                } else if (Integer.TYPE.equals(param[j])) {
                    cost += 3L;
                } else if (Long.TYPE.equals(param[j])) {
                    cost += 4L;
                } else if (param[j].isPrimitive()) {
                    cost += 5L;
                } else {
                    cost += 6L;
                }
            }

            if (cost < 0L || cost > 65536L) {
                cost = 65536L;
            }

            cost += (long)param.length << 48;
            if (cost < bestCost) {
                this._constructor = constructors[i];
                bestCost = cost;
            }
        }

        if (this._constructor != null) {
            this._constructor.setAccessible(true);
            Class[] params = this._constructor.getParameterTypes();
            this._constructorArgs = new Object[params.length];

            for(int i = 0; i < params.length; ++i) {
                this._constructorArgs[i] = getParamArg(params[i]);
            }
        }

    }

根据下面这段代码，从JavaDeserializer的构造方法中可以看出，这里_constructor会被赋予参数最少的那个构造器，即找到ApiException一个参数的构造方法 public ApiException(Throwable cause)，

有根据下面这段代码，我们知道Throwable不是primitive（原始数据类型），所以_constructorArgs值为null。

**this._constructor.newInstance(this._constructorArgs)**使用反射调用构造方法时，要求给的参数必须是原始类型或者其包装器

但是我们给的参数值都为null，，传入的参数不合法，造成了上面的异常。

解决办法

所以绕了这么大一圈知道了原因，那怎么办呢，最简单的方式ApiException提供一个无参的构造方法。就会这样调用：ca.newInstance(new Object[])，即无参构造则不会再抛异常了。

小结

其实这块还会牵扯处很多东西，比如为什么ApiException要那么设计？为什么Java本身的反序列化机制能过而Hession不能过？再比如Constructor.newInstance()和我们经常看到的Class.newInstance()有什么区别？…哎 学海无涯苦作舟