对于计算机系统中的时间，如果你曾经思考过下面的问题，但是没有结论，那么通过本文将给你详细的解答：
时间是一个非常抽象的问题，吸引着许多伟大的神学家、哲学家和物理学家花毕生精力去解释时间的本质是什么，然而依然没有定论。幸运的是我们只需要讨论计算机系统中的时间相关的问题，可以不用关心宇宙、黑洞、相对论和量子力学等等繁复的课题。但虽然仅仅局限在计算机这一个很小的范畴中，这看似已经不再复杂的主题，却并也不会如此简单。
在线应用业务中，数据库是一个非常重要的组成部分，特别是现在的微服务架构为了获得水平扩展能力，我们倾向于将状态都存储在数据库中，这要求数据库能够正确、高性能处理请求，但这是一个几乎不可能达到的要求，所以数据库的设计者们定义了隔离级别这一个概念，在高性能与正确性之间提供了一个缓冲地带，明确地告诉使用者，我们提供正确性差一点但是性能好一点的模式和正确性好一点但是性能差一点的模式，使用者可以按照你们的业务场景来选择使用。
从本质上讲，隔离级别是定义数据库并发控制的。在应用程序的开发中，我们通常利用锁进行并发控制，确保临界区的资源不会出现多个线程同时进行读写的情况，这对应数据库的隔离级别为可串行化（最高的隔离级别）。现在发现离级别其实是和我们日常开发经常碰到的一个概念了吧，那么现在肯定会有一个问题，为什么在应用程序中可提供可串行化的隔离级别，而数据库却不能提供呢？其根本的原因是应用程序的对临界区都是内存操作，数据库要保证持久性（ACID中的Durability）需要把临界区的数据持久化到磁盘，磁盘操作比内存操作要慢好几个数量级（一次随机访问内存、SSD磁盘和SATA磁盘对应的操作时间分别为几十纳秒、几十微秒和几十毫秒），这会导致临界区持有锁时间变长，对临界区资源竞争将变的异常激烈，数据库的性能会大大降低。
本文源自 2010 年的一篇论文 An O(1) algorithm for implementing the LFU cache eviction scheme
缓存置换算法 (Cache Eviction Algorithm) 在操作系统、数据库以及其它系统中被广泛用于缓存置换模块，当缓存空间不足时，它利用局部性原理 (Principle of Locality) 预测未来数据的使用模式，将最不可能被访问的数据清出从而提高缓存命中率。目前已经存在的缓存置换算法包括 MRU (Most Recently Used)、MFU (Most Frequently Used)、LRU (Least Recently Used) 以及 LFU (Least Frequently Used) 等。每个算法都有其各自的适用场景。到目前为止，应用范围最广的是 LRU，主要原因在于 LRU 贴近大多数应用的实际负载模式 (workloads)，同时 LRU 拥有 O(1) 时间复杂度的成熟实现方案。与 LRU 类似，LFU 同样与大多数应用的负载模式相近，但目前 LFU 最佳实现方案的时间复杂度是 O(logn) ，不如 LRU。本文，我们提出一种同样达到 O(1) 时间复杂度的 LFU 实现方案，它支持的操作包括插入、访问以及删除。
本文将按顺序介绍：
组织架构是围绕提高效率而设计的管理形式，任何新出现的组织架构一定是比之前的组织架构效率更高才有意义。中台是近来大家广泛讨论的一种组织架构，但是因为没有明确的定义，所以每一家公司对中台的理解可能会不尽相同。
但是不论什么样的组织架构，落到根本上都是服务好人才、做好事情，所以伴鱼在中台化落地的过程中，总是从这两个角度来评估当前组织架构对于效率的影响，以及应该怎么来优化当前的组织架构。本文回到组织架构的本质——效率的角度，分别从事情和人的角度讨论中台对组织架构的影响，以及伴鱼技术中台的建设与演进过程。
传统互联网公司的组织架构，一般是基于业务发展来设计的，开展新的业务线，组织架构是整体再建设一遍，这样会产生重复建设的问题。如果一个公司有多条业务线的时候，就会出现多个DBA团队，多个运维团队和多个基础架构团队等，这样一件事情在公司内部有多个团队负责，每个团队都需要独立做人才管理和技术积累，从事情的角度来看，复用率是非常低的。
一件事情只由一个团队负责，很多重复的事情只需要做一遍，减少了很多不必要的工作量，并且集中了全公司在这一个方面的人才和资源，这样才能很专业、深入和系统性地把这件事情做好。
中台是最近两年才出现的组织架构形式，一种新的组织架构形式必然会带来协作方式的改变，下面介绍伴鱼技术中台在发展过程中，技术中台内部以及技术中台与业务部门之间协作方式的探索过程，以及分享目前已经形成或正准备实践的最佳协作方式。
基础设施平台化是中台化的基础阶段，伴鱼技术中台早期的时候，我们希望每个团队都能独立负责自己团队基础设施的平台化，比如数据库平台由DBA部门来负责建设，但是在实施的过程中出现比较多的问题：
经过一段时间的摸索后，我们通过临时项目组的方式解决了这样的问题，DBA做产品经理和项目经理，负责数据库平台的产品设计工作和项目管理的工作，在技术中台内部统一协调研发工程师来参与项目，项目完成后临时项目组解散，待下一次平台需要迭代的时候再重新组建项目组进行开发。
这样充分利用了DBA在数据库平台方面的专家经验，并且DBA是平台的使用者，所以数据库平台的产品形态和产品体验都是有保障的；让研发工程师来负责开发，并且研发工程师的 Leader 也会参与项目的讨论，这样平台的研发团队的专业性和质量都是非常有保障的；研发工程师由部门的研发 Leader 来管理，对研发工程师的成长与培养是有保证的。
通过上面的方式，确保了专业的人做专业的事，伴鱼的平台化推进的非常迅速和顺利，目前技术中台除了数据库平台外，运维方面的 CMDB 和 Paas 等平台都是按这个方式做的协作的，非常高效和高质量。
在伴鱼我们要求技术中台打造公司的技术氛围，做技术分享是一种很好营造公司技术氛围的方式，但是选择分享什么样的主题是一个很关键的地方，如果业务部门的工程师对分享的主题不感兴趣，那么大家要么不参加，要么参加后感觉没有收获，不管怎样都是一件非常浪费时间的事情。
在技术中台的发展过程中，我们发现研发工程师对于和他们非常相关的平台或者服务的技术评审是很感兴趣的，这样我们就找到切入点了，通过提高技术评审的质量，将技术分享融入技术评审，同时达到技术评审和技术分享的目的。
现在在伴鱼技术中台，每一个新项目的开发流程是这样的：
技术中台和业务部门是两个独立的部门，业务部门需要依赖技术中台底层能力的支撑，所以如果技术中台和业务部门的沟通不顺畅，那么将是非常严重的问题，也很容易导致业务部门重新造轮子而导致技术中台的价值得不到体现，这将是技术中台部门最大的失败。
伴鱼技术中台在建设的过程中，我们对外非常鼓励业务部门的同事当面来反馈问题，对内强调 Feedback is a gift，确保技术中台和业务部门沟通流畅，通过沟通来解决问题。Feedback is a gift 也是伴鱼技术中台文化的一部分，是伴鱼技术中台人必须做到的事情。
短期和临时的问题，通过当面沟通来解决是非常不错的方式，但是对于长期规划的对齐，就显得力不从心了，通过每季度的 OKR 对齐会是一个非常好的方式。伴鱼是通过 OKR 来进行目标管理的，每一个季度的开始，技术中台和业务部门的研发同事会一起讨论和对齐大家的研发计划，确定业务部门这个季度需要技术中台提供的能力和服务，技术中台也会提一些需要业务部门进行升级解决技术债的需求，一起推动公司的技术进化。
快速响应是研发体验的关键指标，这也是伴鱼技术中台早期就决定确保做到的关键点。将一些长期和关键的要求变成文化，通过文化潜移默化的方式去影响大家是伴鱼在这些事情上的做法，所以业务优先是伴鱼技术中台文化的第一条。现在大家在碰到排期问题的时候，业务优先是第一条需要考虑的准则。
高效响应业务，业务部门就会更愿意通过技术中台的能力来解决它们的问题，而不是自己造轮子。技术中台的目标是提供企业级的复用能力，很多时候，提供企业级的复用能力不是最难的地方，难的是业务部门愿意使用中台提供的能力，所以中台高效响应业务，是研发体验的保障的关键，也是实现中台目标的关键。
这是本文中伴鱼技术中台唯一还没有实践但是一定会尝试的机制。其实这是受到一个偶然机会启发的，有一次业务部门找技术中台借调一个工程师去支持一个紧急需求，差不多一个星期的时间。在这一个星期中借调工程师发现了一些共性问题，业务部门有一些地方没有采用技术中台最新的技术方案，导致一些最新的能力没有在业务部门发挥出来，这是我们非常不期望的事情。
目前技术中台和业务部门的沟通其实是非常顺畅的，我们所有新的技术方案也会实时公告给业务部门，但是业务部门的关注点在业务迭代上，通知与公告这一类的浅影响是很难推动业务部门进行升级的，而轮岗却是一种非常深度的影响方式。一个业务工程师和一个中台工程师交换工作岗位一个星期，业务工程师到技术中台部门工作，充分了解目前技术中台的做事方式和最新的技术方案，中台工程师到业务部门工作，如果发现一些技术债务，则将目前技术中台最佳实践告诉大家，通过这种高效、深度的影响来拉齐中台和业务部门的技术实践方式。
技术中台做得好不好，唯一的评价指标就是研发体验，就像产品做的好不好，用户体验说了算一样。前面的每一条都是提高研发体验的方法，但是研发体验好不好，这个需要研发同事来回答，所以我们决定做研发体验调查。
目前技术中台的研发体验调查每季度一次，通过在线调查的方式进行，技术中台所有的平台和服务以及一些关键的体验指标比如沟通和响应等都是调查的内容，研发工程师对调查指标进行评分，技术中台通过对收集的调查数据进行分析来发现一些需要改进的问题。
特别是对于一些评分比较低的情况，项目的 Owner 需要找到评分研发同事进行一对一的深度沟通来了解评分低的原因，如果是理解的偏差，那么通过沟通解决，如果问题确实存在，那么记录下来并且给好解决问题的截止时间。
每一期的研发体验调查都会形成一个研发体验报告在公司内部公布，目前伴鱼技术中台进行了第一次的研发体验调查，平均评分最低的项目得分为4.3（5分制），这是一个非常好的开始，能获得业务部门研发同事的认可，对于技术中台来说是最一件非常值得骄傲的事情，当然我们还会努力做到更好。
由于技术中台和业务部门是独立的部门，所以保证技术中台能够真正实现提供企业级的复用能力的关键除了技术因素外，中台和业务部门的协作方式也是一个非常重要的影响因素，本文从六个方面来描述了伴鱼技术中台和业务部门的协作方式：
并且，目前伴鱼技术中台通过上面的协作方式获得了研发部门非常好的研发体验评价。
口头沟通短期效率高但是长期效率低，文字沟通则正好相反。对于规范、流程等长期价值高的知识和经验，鼓励大家通过文档等文字沟通的形式来进行，而对于日常临时、突然等长期价值低的问题，鼓励大家通过当面口头沟通的形式，高效率沟通。
日常的工作内容，口头沟通的效率是高于通过钉钉和微信等软件沟通的，直接找到负责人的横向沟通的效率是高于向上汇报的纵向沟通的。非常推荐大家碰到临时、突发并且预计几分钟可以解决的问题时，找到事情的直接负责人，当面进行一个临时的站立会议，快速通过口头沟通达成一致。如果问题涉及的人数比较多，短时间内很难有结论，那么约一个正式的会议会是一个很好的选择。在沟通中达成一致的结论，如果有长期价值的结论，可以在沟通群中同步或者文档中心通过文字的形式记录下来。
在kubernetes中要保证容器之间网络互通，网络至关重要。而kubernetes本身并没有自己实现容器网络，而是通过插件化的方式自由接入进来。在容器网络接入进来需要满足如下基本原则:
一个Linux容器的网络栈是被隔离在它自己的Network Namespace中，Network Namespace包括了：网卡(Network Interface)，回环设备(Lookback Device)，路由表(Routing Table)和iptables规则，对于服务进程来讲这些就构建了它发起请求和相应的基本环境。而要实现一个容器网络，离不开以下linux网络功能:
网桥: 网桥是一个二层网络虚拟设备,类似交换机,主要功能是通过学习而来的Mac地址将数据帧转发到网桥的不同端口上.
路由: Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里
基于以上的基础，同宿主机的容器时间如何通信呢？
