云原生越来越火了，无论是企业内部，还是技术论坛，上到应用架构，中到数据库存储，下到基础设施，无不谈云原生。可是云原生到底是什么，容易让人感到概念混乱不清。其实这不怪大家，这个概念太新了，不但大家困惑，业内大牛也在不断的改变着定义，直到现在才稍稍有所统一。一、混乱且不断变化的云原生定义1.1.云原生定义之乱我们来看看这些大牛们都如何定义云原生的：2010年，WSO2技术总监PaulFremantle

在真正的生产实践过程中，对于CPU的隔离要求比容器的默认策略要严格的多，因而需要对于Linux内核底层机制有所理解，才能很好的做CPU隔离，甚至在离线业务混合部署隔离等策略。本文不打算讲述Cgroup的使用层原理，因为这类文章已经比较多了，而是希望从更深层的原理去解析。一、系统的初始化与Cgroup的初始化cgroup的机制起作用要从Linux系统的初始化开始。内核是如何初始化的呢？内核的启动从入口函数start_kernel()开始。在init/main.c文件中，start_kernel相当于内核的main函数。打开这个函数，你会发现，里面是各种各样初始化函数XXXX_init。在操作系统里面，先要有个创始进程init_task，它的定义是struct

Cgroup的配置起作用在进程申请内存的时候，也即当出现缺页，调用handle_pte_fault进而调用do_anonymous_page的时候，会查看是否超过了配置，超过了就分配失败，OOM。

除了容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。

所以不能再运维组和开发组隔离了，而要成立架构师组，或者就像前面图中的架构委员会，当然这个架构组一开始试点不用很大，试点阶段一定要有这个角色，来横向协调各种资源，并且挂在CIO下面，有一定的话语权。

本文内容选自中国DevOps社区年会

Mesh并不是什么新的技术，它所关注的高性能、高可用、服务发现和治理等有服务化的一天就已经存在，社区也不不乏这方面的最佳实践。不不过之前主要是两种方式，一种是微服务RPC框架形式，例如Motan,

最近中台的文章比较多，大多数谈历史，谈原因，之后就是谈技术了，但是中台真的实施起来，却躲不开下面的灵魂拷问。问题一：到底哪些应该作为中台，哪些不应该作为中台，是谁决定的？如何决定的？问题二：每一个中台应该有哪些功能？谁来定义？和业务方如何切分？怎样保证切分的合理？每一个中台应该有多大？按接口数？代码行数？什么时候决定再拆分？谁决定？问题三：维护每一个中台的团队应该有多大？10个人？100人？用户中心和商品中心应该哪个人多哪个人少？什么时候能扩招？谁来定？绩效如何？谁来定？问题四：和业务方的矛盾如何处理？业务方是否一定要用中台？谁有权要求业务方一定用中台？看完了这些问题，你可能会觉得这些问题还不够深入灵魂，因为大部分人觉得只要有一个英明神武的CIO或者CTO，加上一个英明神武的中台技术委员会，就可以解决上面的问题了。但是如果仔细想一下一个具体落地的场景，你就会发现，这事儿没这么简单。例如：中台技术委员会定下来，要构建一个商品中心，组织应该有100人，服务提供50个接口，接口之外的功能都属于业务方定制化需求，所有业务方必须要用商品中心否则枪毙。这个时候，我们就可以把问题问的更加深入灵魂一点。问题一：为啥商品中心是，xxx中心就不是，你怎么知道商品中心能够复用，xxx中心不能，谁长前后眼了吗？问题二：为啥是100人，不是50人，不是150人，你能精准评估人力吗？业务方因为赚大钱狂招人，中台组跟的上吗？问题三：为啥xx接口和功能应该属于中台，yy接口和功能不应该属于中台，每个接口都要评估嘛？评估的过来吗？技术委员会了解技术细节吗？为什么他们评估的就是对的？会不会业务方不满当前接口和功能不使用？问题四：业务方一定要用中台服务吗？不用能把他怎么样？如果业务方说中台耽误他们赚钱了怎么办？中台的老大有业务的老大强势吗？业务方自己偷偷实现一个商品中心wrapper怎么办？技术委员会天天review代码，看注册中心吗？这个时候你会发现一个矛盾点，就是技术委员会如果足够高level，就往往无法深入细节，哪怕下面进行汇报也无从判断，如果足够细节，往往level就不太高，则无法控制业务方一定使用中台。诸葛亮式（计划经济式）中台模式那可不可能Level又高，又精通细节的呢？有，就是这种人太难找了，这就是诸葛亮啊。三国演义说，诸葛亮身为丞相，Level既高，并且“早起晚睡，凡是二十杖以上的责罚，都亲自披阅”。这就是中台构建的第一种思路：诸葛亮式，也可以叫计划经济式。这种思路有以下的特点：第一：技术委员会具有绝对权威，其依靠的组织的组织目标是统一的，业务方向也相对单一。就像诸葛亮之所以能够揽大权与一身，调动整个蜀国的力量，是有北伐这个统一的目标。所以这种模式比较适合业务方和中台方的组织目标统一，业务方向统一，归同一个技术委员会管理的情况，多见于BU级别的中台，或者整个公司当前的组织不大，业务相对单一的时候。第二：技术委员会对于细节把控要足够细，甚至亲自review接口和架构，单一业务的CTO或者首席架构师可担任。就像诸葛亮连下层士兵打板子自己都要亲自过问。这种模式要求组织不大，CTO这个级别的人能够了解足够细节，才能够准确判断中台的界限，哪怕下面人来汇报打官司，也能够做到英明神武。但是这一点，就可以排除大部分超大型公司了。第三：技术委员会对于中台组织和业务方的绩效，招聘，奖惩都有权力，才能保证策略执行。第四：技术委员会要做好鞠躬尽瘁996的准备了。权利和义务相对等，什么都归你定了，每天一万人来找你拍板。而且诸葛亮勤奋，但是不代表只要勤奋就能成为诸葛亮，鞠躬尽瘁的人好找，鞠躬尽瘁又是诸葛亮的就难了。如果公司真的能够找到诸葛亮一样的人物，并且建立起来这样一套机制，那上面的问题倒是能够解决了。第一：哪些应该作为中台由CTO或者首席架构师拍板，当然会出错，可拆分再融合。第二：中台应该有哪些功能以及和业务方如何切分模式由技术委员会统一review敲定，因为中台方和业务方技术委员会都了解细节并且都有话语权，所以可保证合理性，也可随时调整第三：维护每一个中台的团队应该有多大由CTO或者首席架构师决定，如遇到业务方和中台方人员不匹配的情况，CTO或者首席架构师可决定给中台组招人，并制定绩效第四：技术委员会可决定业务方一定要用中台，因为了解足够细节，可通过review接口，工程，注册中心保证业务方一定用中台，因为可控制绩效，对于没有使用中台的业务方可进行惩罚。这种计划经济式的中台构建模式，往往难度比较大，事实往往就像当年计划经济的委员会没办法知道某一条街道到底应该放五个煎饼摊，还是两个煎饼摊一样，这个委员会也绝没有英明神武到仅仅通过开会评估，就把上面的这些问题搞定。市场经济的中台模式

一、微服务落地是一个复杂问题，牵扯到IT架构，应用架构，组织架构多个方面在多家传统行业的企业走访和落地了微服务之后，发现落地微服务是一个非常复杂的问题，甚至都不完全是技术问题。当时想微服务既然是改造应用，做微服务治理，类似注册，发现，熔断，限流，降级等，当然应该从应用开发组切入，一般一开始聊的会比较开心，从单体架构，到SOA，再到微服务架构，从Dubbo聊到SpringCloud，但是必然会涉及到微服务的发布和运维问题，涉及到DevOps和容器层，这些都不在开发组的控制范围内，一旦拉进运维组，对于容器的接受程度就成了一个问题，和传统物理机，虚拟机的差别，会带来什么风险等等等等，尤其是容器绝对不是轻量级的虚拟化这件事情，就不是一时半会儿能说的明白的。更何况就算说明白了，还有线上应用容器，一旦出了事情，谁背锅的问题，容器往往会导致应用层和基础设施层界限模糊，这使得背锅双方都会犹豫不决。

对于怎么用，上手的话，推荐《鸟哥的Linux私房菜》，按着这个手册，就能够学会基本的Linux的使用，如果再深入一点，推荐《Linux系统管理技术手册》，砖头厚的一本书，是Linux运维手边必备。

routeConfigProvider()返回的就是RdsRouteConfigProviderImpl，其config函数返回的就是ConfigImpl，也就是上面我们描述过的层级的数据结构。

如何从出口的运营商到达云平台的边界路由器？在路由器之间需要通过BGP协议实现，BGP又分为两类，eBGP和iBGP。自治系统间，边界路由器之间使用eBGP广播路由。内部网络也需要访问其他的自治系统。

在IP头里面，都需要加上自己的地址（即源地址）和它想要去的地方（即目标地址）。当一个手机上线的时候，PGW会给这个手机分配一个IP地址，这就是源地址，而目标地址则是云平台的负载均衡器的外网IP地址。

由于有两个可用区，在这个VPC里面，要为每一个可用区分配一个Subnet，也就是在大的网段里分配两个小的网段。当两个可用区里面网段不同的时候，就可以配置路由策略，访问另外一个可用区，走某一条路由了。

访问外部服务包：如果这个进程要访问其他进程，对于外部访问的封装都在这里，对于单元测试来讲，对于这部分的Mock，可以使得不用依赖第三方，就能进行功能测试。对于服务拆分，调用其他的服务，也是在这里。

IaaS(33),大数据(9),容器(17),微服务(2),人工智能(3)

pilot将管理员输入的转发策略配置和服务发现的当前状态，变成pilot自己的数据结构模型，然后暴露成envoy的api，由于是envoy来调用，因而要实现一个服务端，这里有lds,

当系统非常复杂的时候，要有统一的监控，主要有两个方面，一个是是否健康，一个是性能瓶颈在哪里。当系统出现异常的时候，监控系统可以配合告警系统，及时地发现，通知，干预，从而保障系统的顺利运行。

但是缺点也比较明显，Memcached严格来讲没有集群机制，横向扩展完全靠客户端来实现。另外Memcached无法持久化，一旦挂了数据就都丢失了，如果想实现高可用，也是需要客户端进行双写才可以。

而宣传有状态容器的自动重启，对于服务客户来讲是很不经济的行为，因为客户往往没有那么清楚应用的逻辑，甚至应用都是买的，如果使用有状态容器，任凭自动重启，最终客户发现数据丢失的时候，还是会怪到你的头上。

当然第二名的技术也是非常棒的，有了OpenStack之后，果真像Rackspace想的一样，所有想做云的大企业都疯了，你能想象到的所有如雷贯耳的大型IT企业：IBM、惠普、戴尔、华为、联想等都疯了。

在实行了无状态化之后，就可以将有状态的集群集中到一起，进行跨机房的部署，实现跨机房的高可用性。而无状态的部分可以通过Dubbo自动发现，当进程挂掉的时候，自动重启，自动修复，也可以进行多机房的部署。

更新一个字段意味着相应的索引也要更新，更新往往意味着删除然后再插入，索引本来是一种事先在写的阶段形成一定的数据结构，从而使得在读的阶段效率较高的方式，但是如果一个字段是写多读少，则不建议使用索引。

所以应该在接入层nginx中配置动态资源和静态资源的分离，将静态资源的url导入到nginx的本地缓存或者单独的缓存层如varnish或者squid，将动态的资源访问后端的应用或者动态资源的缓存。

meeting，为什么要站着呢？因为时间不能太长，微服务的一个模块，大概需要5-9人的团队规模，如果团队规模太大了，说明服务应该进行拆分了，这个团队规模，是能够保证比较短的时间之内过完昨天的状态的。

对于Kubernetes，绝对推荐这个https://github.com/opsnull/follow-me-install-kubernetes-cluster，写的非常详细，并且完全手动。

客户开始口若悬河的描述他们想怎么处理这些数据，例如每个都加一（map），过滤掉一些（filter），合并一下（union），按照key做个汇总（reduceByKey），最后处理完了，写入HDFS。

除了容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。

在内核中首先从CPU寄存器中拿到系统调用号，然后在这个表中查找open系统调用对应的内核函数，经过查抄对应的是sys_open，于是开始调用sys_open真正的打开一个文件。

Descriptor在文件描述符列表中，也在打开的文件列表中，而指向一个仅仅在内存中的inode，通过socket指向一个socket的结构。

AMs的人说，接了项目，弄个项目经理ApplicationMaster(MRAppMaster)吧(startContainter)，专门负责这个项目的对接。于是在一个团队里面Node

link文件，指向其他的文件，例如/etc/systemd/system/multi-user.target.wants中的文件指向/lib/systemd/system/中的相应的文件。

这样整个网络的拓扑结构就不是硬的了，也即不是通过插线，拔线，登陆盒子配置的，而是变成了软的，也即通过软件统一控制，这个统一控制的地方我们称为SDN

https://k8smeetup.maodou.io/course/ZMwdAFuzBdXtNySiW

子进程有独立的task_struct结构，有自己的PID，在fork的当下，代码段是和父进程是一样的，一般会被exec系列函数重新加载新的代码段，数据段和栈是新创建的，采取的copy

假设一款游戏，Game，它的owner是Jerry，当Jerry玩这个游戏的时候，成功闯关，会将当前的通过的关卡写入Result文件，从而下次登录的时候，就可以接着上次的玩了。

当进程收到SIGSTOP信号的时候，例如在shell中ctrl-z或者debug程序的时候到达断点，进程进入到TASK_STOPPED状态，当收到SIGCONT的时候，恢复执行。

除了容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。

cache，顾名思义是一个缓存，为了查询快的，从系统启动开始，所有被引用过的文件，都会在这里缓存一下，在dentry结构里面有hashlist，可以方便通过文件或者路径名进行查找，有lru

如果每个源文件太小，例如每个文件1k，则每个文件一个map任务，这样并行的任务太多了，因而可以使用CombineFileInputFormat，减少并行的数目。

1、分词，讲文本分词形成这个文章的特征单词。最后形成去掉停词之类的单词序列，并统计每个词出现的数目tf作为权重

在每个迭代中，其次Analyzer会基于上面的映射关系和nodes库，计算To的这个网页的score，score(To)=sum(score(from))，也即将from的每个score加起来。

Parse从content里面读取网页的内容，通过解析，一部分是网页的正文文字，放在parse_text里面，一部分是网页的链接，放在craw_parse里面，这里面的链接是可以再次爬取的。

云平台是高可用的，管理节点一般三个，挂一个没问题的。服务器和虚拟机是高可用的，服务器挂了，虚拟机能迅速迁移到另外一台，容器更快，秒级启动，而且可以一个电商应用跑个十份八份的，既能高可用，也能撑流量。

作为一个分布式系统，每一层都会有自己的API，但是对外往往需要一个统一的API接口层，一般除了酷酷的界面之外，为了自动化，往往会有一个命令行可以执行操作，其实命令里面封装的也是对API的调用。

例如有的用户完全不想操心，则使用存储层面的异步复制，对于存储设备来讲，是无法区分放在存储上的虚拟机哪台是重要的，哪台是不重要的，完全根据块进行复制，很可能先复制了不重要的虚拟机。

network里面的switch都是强大的switch，为了提供高可用性，然而又不需要STP，则多个switch之间Link

shares，执行3个用户A的任务，执行2个用户B的任务。三个用户A的任务总共消耗了{3CPU，12GB}，两个用户B的任务总共消耗了{6CPU，2GB}；在这个分配中，每一个用户的dominant

然而在虚拟机里面跑容器的方式，是不需要cloud-init的，因为灵活定制化的事情由里面的容器来做，用户使用的也是里面的容器，而不是虚拟机，因而虚拟机可以做的十分的精简，将不需要的服务全部删除。

Flannel在每台机器上，还是传统的二层网络，然后通过一个flanneld进程，将包封装为UDP的包，再加上服务器的IP和MAC，到达另一端的flanneld，就会解封装，然后转发给容器。