47 | 服务治理的宏观视角

数据中心操作系统后续会深入讲解吗

老师我有个疑问希望你帮我解答一下，你在前边讲桌面端操作系统和服务端操作系统分道扬镳的标志是s3这类对象存储系统的出现。 但是对于运行进程的服务环境来说，我们今天使用docker，使用k8s这类虚拟化技术的确有了很大的便捷性，但是这存在一个前提：我们在linux安装docker和k8s，然后在k8s调度各种进程，网络服务，或者存储接口，所以本质还是在linux操作系统中需要安装k8s和docker软件，那么为什么没有人去开发一个专用于虚拟化环境的操作系统，这个操作系统直接安装在裸机之后就直接拥有了当前容器技术的所有特性，可以方便的组分布式集群，使用各种虚拟化功能呢？

现在不是有一个发现服务的东西，发现服务提供服务，服务治理会不会比以前要轻松些。 还有就是docker和K8s，我知道k8s更好，但是又说不出来哪里好，实际上都是里面扔东西，我自己玩的话还是喜欢docker，毕竟一大堆现成的拿来直接玩，老师怎么看待这两者，K8S到底有什么过人之处呢？

不太明白自主化具体是什么概念，是指具备人工智能吗？

讲的真好，提个小意见，音频语速有点儿快，有时感觉像机器念的一样。

Google SRE其实换到其它行业其对应的属性个人多年DBA&&OPS的经验感觉：其实现在已经不再是Google SRE的最初解释了，就像现在的OPS要做好OPS的事情其实至少应当具备DevOps或者全栈工程师的能力，近半年一直在极客时间去学习、反思、探索，其实现在的Ops应当是以过去的Ops为主且兼备全栈的能力，就像老师课程中所说的服务治理建立自治化系统。

第一次听到SRE(网站可靠性工程师)这个名字,我们做的是政务系统,一个系统上线到一个地方,都面临定制化开发的问题,于是就需要版本管理,但是地方上可能还会有更加具体的定制化,比如一个系统,要分为演示系统和实际应用系统两个版本,到最后一个市最多的时候出现过近40个不同版本. 但是统一版本的话也会有问题,就是我们的系统在不断更新新的功能,如果隔上一段时间后,再给某个原先的生产环境更新系统的时候会出现版本不一,致导致的应用问题. 关于版本过多维护困难,我能想到的解决方案就是增加人力资源;新版上线导致老版本无法正常运行,属于向下兼容没做好,需要在推进开发的时候,只做新增,不做修改或删除. 还有我对微服务具业务拆分也有问题,如果我们把用户认证做成一个单独的服务,来为其他服务服务,那么如果用户认证服务没有了,其他服务岂不是都用不了,不是要解耦吗?这个具体场景我还能理解,因为基础架构是业务架构的基础,就像是计算机硬盘用不了,那么其他建立在计算机上的应用都就用不了了.可其实我遇到最多疑惑的是,我们的业务之间不可避免的有关联,比如订单模块要关联商品模块,那么订单系统是否对要有能力独立,在其商品个模块挂了的情况下,依然可以查询订单的情况?我想是应该的,作为订单系统,自身有和其他业务重合地方,比如展示商品图片和价格.那么当我们订单模块要查询商品信息时,是否应该使用商品模块的查询接口而不是自己写一个查询接口? 还有我们部门昨天开了会讨论研发和实施(运维)的边界问题,讨论最多的问题就是实施人员和研发人员共识信息太少,既包含业务共识,也包含技术共识,研发这边的信息量明显可以碾压实施的信息量,导致每次解决线上都需要研发人员亲自动手,最后问题会花费成倍的时间,于是我建议,生产环境一个技术人员/开发环境一个技术人员.网站可靠性工程师,听起来更专业,名字里就诠释了他要做的事情.

学习打卡

服务涉及的概念（可以理解为节点）很多，不同节点之间相互关联构成一个复杂的系统，而它又是一个自身动态持续迭代升级，与之相关的业务也在持续地迭代发展，导致复杂度持续升高，必然导致服务治理也更加复杂。服务自治是更好的解决方案。

再谈谈对自动化和自主化的理解,自动化只是自动的做一些事情,这事对不对要人来判断,但自主化解决了一类线上系统面临的通用问题---硬件老化.将服务部署在物理环境,那就少不了要维护硬件和面临硬件带来的可靠性问题.自主化是说在虚拟环境部署系统,虚拟环境中的硬盘就不是指这个环境某个具体的硬盘,而是硬盘一堆硬盘,一个坏了立马自己替换一个.保证服务的可靠性.也就是这事对不对它自己知道.