[北京站DevFest]我真的什么都不知道….
今天是北京时间2020-02-03，这是一篇本该在2019-12-30发布的文章，显然，我咕咕了。的确很多事情都很难料，活动在12-08就结束了，至于感言和其他乱七八糟的东西我在十二月二十的时候就整理的差不多了，可是莫名奇妙的一个版本插队，以及带学下铺兄弟的造访（我不是给他帅锅），然后这篇最终也拖了很久，本来铁废物系列是有十篇的，目前这篇才到第九篇。有一说一我虽然知道2020会很糟糕，但是开幕雷击，比我想的复杂多了。但我嘴上叫着，但是心里明白，技工行业如果还要看外界脸色，大概率走不远了。废话不多说，吐槽的话自然有吐槽的篇幅，我们认真看下那天的流水账吧：
迫于不想在家发霉，所以决定走出去看看（[2019-12-10]现在感冒了难受的...）。三翻两翻看到了之前关注的GDG北京公众号的文章，说是第八届北京DevFest在京举办。我大概看了下时间是周日，计算了下自己手头的事情就决定去看看...毕竟其中有场我比较感兴趣的ServiceMesh的分享。
然后前一天晚上我稳定作死，在12/07那天，我忘记了给手机充电。
然后我早上十点就拿着电量只有13%的手机出门了。早上去医院还要靠APP各种短信验证，然后电量成功被磨到了2%。当我冲进二号线地铁的时候..手机已然关机了。
到达目的地的地铁站之后我意识到一个问题：没有导航我咋过去....emmmmm，在国家图书馆门前楞了下：
于是我非常囧的去了一家小卖部，以先嫖后付的方式..给手机充了点电之后我高价租了某共享充电宝，加上购买的ype-c充电线，免费的活动一下有了资本支出...
当然有了导航我还比较EZ地到达了会场：
本来今天就是冲着ServiceMesh来的（因为公司是强行上的微服务，但究其本身并不具备微服务化的条件，而对于服务拆分和微服务化，铁定是因场景变化为了解决某种问题或者提高服务健壮性而all in）
由于第一位和第二位所讲的内容大部分和公司曾今的分享重合，（尤其是K8s相关的内容，重合程度几乎100%，让我怀疑他们是不是下载的同一份ppt// 这里没有黑的意思，本身我对这部分了解不多，听再多并无实践经验，他们所 遇到的痛点、难点由于分工不同我并不能很好的体会，并不代表他们的分享有问题，从提问和回答来看，他们的确遇到和解决了一些微服务的高频问题:高可用、健康检查、服务状态监控、磁盘挂载、负载均衡、重试等）这里直接in Service Mesh 的：
首先关于这个人，可以在很多分享和沙龙看到，当然演讲的内容大都和ServiceMesh相关，话不多说，跟着他的PPT来（图源来自GDGBeijing，
讲义地址：Service Mesh Why/When/What
现场录制：Service Mesh 落地之 Why/When/What 演讲篇 - 蔡书 ）：
首先他介绍了背景，说自己以前人在红帽，给银行做。但是由于银行的内部系统技术/语言/框架都不是很统一，且服务间通信/协议也并不是单一的。
接着说明了想要满足的功能和系统存在的问题以及痛点与诉求
(ppt未提及)其中提到了：SDN
https://blog.csdn.net/AtlanSI/article/details/95613225
而后续则提及了上Mesh的时机，其实也算是微服务的When....(别给我说真有人不知道SLA的..: 服务等级协议（简称：SLA，全称：service level agreement）。是在一定开销下为保障服务的性能和可用性 ,老板喜欢提，手动狗头)
以上其实已经说明了构建微服务/Service Mesh的时机和原因...接下来就该结合我司情况进行吐槽了。
我司的技术升级架构准备了很久，因为在19年初和三月的时候，都由于各种技术问题导致服务器宕机，但是宕机带来的影响却是整个线上服务的瘫痪。因为单体服务和单库的风险就是在于如果服务的某个模块有问题，整个服务都处于不可用的状态，说白了就是耦合性过高，我们的服务其实并不集中，部署的也相对分散，但是服务之间的依赖很严重，加上使用的主库却只有一个，数据库在线上往往承受着最大的压力，从这点来看我们基于利用分布式系统来解决ze单DB高IO的问题，属实迫在眉睫。
单从这点来看没毛病，但是上文也提到了，在 上微服务时需要有对服务的管控和治理能力，而这点经过测试环境半年多的实践其实公司的DEVOPS完全ok，自研的cmds其实对服务的管控还是比较到位。
此时我们似乎具备了一半的条件，再来看最重要的事情：SLA。其实上面这些都是Tech方面的问题，但是作为一家要盈利的商业公司，上面的这些东西并不具备你转型或者更替服务的理由，真正能够起决定性作用的是SLA。原因是业务部门并不在乎Java还是Go，不在乎Dubbo还是Rest，他们只关心稳定，正确，快速。所以最后一点是我们CEO帮忙执行的，但就2020-02-03 的情况来看，我们的这一步走的不是很正确。
拆分的很散的服务带来的是治理难度的直线上升，经历裁员之后明显感知到不管从维护角度来看也好，还是从开发角度去看也罢，都是很费时费力的一件事情，处处需要小心的分布式事务，服务间通信、重试等机制随着业务场景的变化，这都是拆分给开发人员带来的问题。而由于经验和方式的错误，可能对应的在健壮性上也要打上问号了。SLA？哈哈哈哈哈
不多说了，说多了都是罪过
剩下还有部分 的内容即What其实是ServiceMesh相关的。我想视频讲的应该比我清楚多了：