| 以下内容已屏蔽图片优化访问速度 |
|---|
|
本文根据刘超在DBAplus社群第122期线上分享整理而成 无论是在社区，还是在同客户交流的过程中，总被问到底什么时候该用Docker？什么时候用虚拟机？如果使用容器，应该使用哪个容器平台？显而易见，我不会直接给大家一个答案，而是希望从技术角度进行分析具体的场景，例如客户是大公司还是小公司，将部署小集群还是大集群，倾向于私有云还是公有云，已经采购了IaaS还是没有IaaS，IT运维能力强还是弱，是否需要物理机、虚拟机、容器的混合部署，是一般的并发系统还是高并发，这里面所应该做的技术选型都不一样。 例如，如果你是一个初创型的主营业务非IT的小公司，自然不应该花大力气在数据中心里面自己搭建一套大规模、高并发、高性能的容器平台。 首先我们来谈什么情况下应该使用Docker的问题 [IMG] 如图，左面是经常挂在嘴边的所谓容器的优势，但是虚拟机都能一一怼回去。 如果部署的是一个传统的应用，这个应用启动速度慢，进程数量少，基本不更新，那么虚拟机完全能够满足需求。 应用启动慢：应用启动15分钟，容器本身秒级，虚拟机很多平台能优化到十几秒，两者几乎看不出差别 内存占用大：动不动32G，64G内存，一台机器跑不了几个 基本不更新：半年更新一次，虚拟机镜像照样能够升级和回滚 应用有状态：停机会丢数据，如果不知道丢了啥，就算秒级启动有啥用，照样恢复不了，而且还有可能因为丢数据，在没有修复的情况下，盲目重启带来数据混乱。 进程数量少：两三个进程相互配置一下，不用服务发现，配置不麻烦 如果是一个传统应用，根本没有必要花费精去容器化，因为白花了力气，享受不到好处。 [IMG] 什么情况下，才应该考虑做一些改变呢？ 传统业务突然被互联网业务冲击了，应用老是变，三天两头要更新，而且流量增大了，原来支付系统是取钱刷卡的，现在要互联网支付了，流量扩大了N倍。 没办法，一个字：拆！ 拆开了，每个子模块独自变化，少相互影响。 拆开了，原来一个进程扛流量，现在多个进程一起扛。 所以称为微服务。 [IMG] 微服务场景下，进程多，更新快，于是出现100个进程，每天一个镜像。 容器乐了，每个容器镜像小，没啥问题，虚拟机哭了，因为虚拟机每个镜像太大了。 所以微服务场景下，可以开始考虑用容器了。 [IMG] 虚拟机怒了，老子不用容器了，微服务拆分之后，用Ansible自动部署是一样的。 这样从技术角度来讲没有任何问题。问题是从组织角度出现的。 一般的公司，开发会比运维多得多，开发写完代码就不用管了，环境的部署完全是运维负责，运维为了自动化，写Ansible脚本来解决问题。 然而这么多进程，又拆又合并的，更新这么快，配置总是变，Ansible脚本也要常改，每天都上线，不得累死运维。 所以在这如此大的工作量情况下，运维很容易出错，哪怕通过自动化脚本。这时，容器就可以作为一个非常好的工具运用起来。 除了容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。 这样做的好处就是，虽然进程多，配置变化多，更新频繁，但是对于某个模块的开发团队来讲，这个量是很小的，因为5-10个人专门维护这个模块的配置和更新，不容易出错。 如果这些工作量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量会大非常多。 容器是一个非常好的工具，就是让每个开发仅仅多做5%的工作，就能够节约运维200%的工作，并且不容易出错。 然而原来运维该做的事情开发做了，开发的老大愿意么？开发的老大会投诉运维的老大么？ 这就不是技术问题了，其实这就是DevOps，DevOps不是不区分开发和运维，而是公司从组织到流程能够打通，看如何合作，边界如何划分，对系统的稳定性更有好处。 所以微服务、DevOps、容器是相辅相成，不可分割的。 不是微服务，根本不需要容器，虚拟机就能搞定，不需要DevOps，一年部署一次，开发和运维沟通再慢都能搞定。 所以，容器的本质是基于镜像的跨环境迁移。 镜像是容器的根本性发明，是封装和运行的标准，其它什么namespace，cgroup，早就有了。这是技术方面。 在流程方面，镜像是DevOps的良好工具。 容器是为了跨环境迁移的，第一种迁移的场景是开发、测试、生产环境之间的迁移。如果不需要迁移，或者迁移不频繁，虚拟机镜像也行，但总是要迁移，带着几百G的虚拟机镜像，太大了。 第二种迁移的场景是跨云迁移，跨公有云，跨Region，跨两个OpenStack的虚拟机迁移都是非常麻烦，甚至不可能的，因为公有云不提供虚拟机镜像的下载和上传功能，而且虚拟机镜像太大了，一传传一天。 所以跨云场景下，混合云场景下，容器也是很好的使用场景。这也同时解决了仅仅私有云资源不足，扛不住流量的问题。 所以这是我认为的容器的本质，是最终应该使用容器的正确姿势，当然一开始你不一定完全按照这个来。 模式一：公有云虚拟机 适合场景：初创公司，无信息安全担忧 如果您是一家初创公司，人员少，IT运维能力不足，要部署的系统很少，能够花在IT系统上的资金有限，当然应该选择公有云的虚拟机部署，它能够解决您的如下问题： 基层IT资源的管理交给公有云平台，公司自身运维人员仅需要基本的Linux能力 少量的部署系统，例如10台以下的虚拟机，往往替换一个war，重启Tomcat就能解决，如果稍微虚拟机多一点10到20台，Ansible脚本可以很好的解决这个问题 公有云按量按时收费，可以在花费很少的情况下启动，并且在业务飞速扩展的时候，迅速申请大量虚拟机 这里所说的信息安全担忧，真的仅仅是心理的担忧，公有云往往有大量的安全机制来保证每个租户的安全隔离，只要用好了这些机制，公有云的安全性绝对大于一般的公司自己搭建的数据中心，为什么呢？ 大家有兴趣可以阅读《当客户在说要安全的时候，客户在想什么？》，绝对的端到端解决方案。 这里贴张图说明公有云的安全性。 [IMG] 公有云为支撑自身高并发业务积累了更强的安全防护能力和更多的安全防护经验： 多线BGP，外网线路冗余 高吞吐量的DDoS外网防护 更完善的防火墙，入侵检测，WAF 更完善的流量清洗规则 公有云为支撑自身高并发业务推出了更安全、更高可靠、更高可用的PaaS服务： 数据库： 高可用：主备切换数据零丢失 高可靠：同城双活，异地备份 安全性：访问控制，IP白名单 对象存储： 高可靠：超大容量，三份备份，异地同步 安全性：访问控制，防盗链 公有云为支撑自身高并发业务推出更完善的监控运维的系统，流程，经验： 完善的监控系统，保障大促期间系统故障的快速定位和排障 保障大促能够极大的提升和训练一支有经验的运维团队 大促的业务层面的数据对运维也是机密的，需要流程保障 道高一尺魔高一丈，公有云为保证自身业务的安全性对云平台不断升级： 越来越强的DDoS防护 越来越完善的防火墙规则 最新的云平台安全功能和机制 不断更新的虚拟机和容器镜像建设漏洞 不断更新的病毒库 这不是今天的重点，这几张图大家自行参考。 模式二：无IaaS，裸用容器 适用场景：初创公司无IaaS，有信息安全担忧 但是即便如此，还是有初创公司或者初创项目，也许因为心理方面，也许因为合规方面，非常担心信息安全问题，还是希望采取部署在自己机房的方式。 但由于是初创公司，在机房里面一般是不能部署IaaS，因为IaaS平台的运维难度，优化难度更大，没有一个50人的团队根本玩不起来，所以一般在使用容器之前，采用的是物理机部署的方式，当物理机数目非常小，比如部署5到10个应用的时候手动部署或者简单脚本部署就可以，但是一旦到了20个应用，手动部署和简单脚本就非常麻烦了： 运维人员比例低，而应用相对较多 部署在同一个物理机上的应用多，配置冲突，端口冲突，互相连接，运维需要一个excel去管理，还容易出错 物理机容器被脚本和Ansible改的乱七八糟，难以保证环境一致性，重装物理机更加麻烦 不同的应用依赖不同的操作系统和底层包，千差万别 这个时候，可以试一下裸用容器，即在原来的脚本，或者Ansible里面，将启动进程，改为使用Docker run，可以有以下的作用： 配置，端口隔离，冲突减少 基于容器部署，使得环境一致性，安装和删除干干净净 不同的操作系统和底层包，都可以用容器镜像搞定 在这个阶段，最简单的方式就是把容器当做虚拟机来使用，也即先启动容器，然后在里面下载war包等，当然也可以更进一步，将war包和配置直接打在容器镜像里面，这样需要一个持续集成的流程了，不仅仅是运维的事情，开发也要参与其中。 在这个阶段，网络的模式可以使用桥接打平的方式。 [IMG] 这种方式好处是访问Docker和访问物理机一样，可很方便地实现Docker里面和物理机里面的互通，兼容原来部署在物理机上的应用。 当然Bridge的性能一般，如果性能要求比较高，可使用SR-IOV网卡嵌入容器内。 [IMG] 模式三：有IaaS，裸用容器 适用场景：创新项目，引入DevOps流程 有一些公司规模大一些，已经采购了IaaS，只不过有一些创新的项目需要部署，这种状态下，基本虚拟机已经能够满足需求，而且由于能够运维IaaS，IT能力比较强，一般也采用了Ansible等部署工具。 这种情况下，使用容器的动力相对比较少，然而容器也是能够带来一定好处的，就是DevOps。 创新项目迭代速度比较快，如果有比较多的创新项目，对运维的压力也是非常大的，这里的裸用容器和模式二的裸用容器不同的是，不是拿容器当做虚拟机来用，而是将容器当做交付物来用。虽然容器化对于运维的整个过程来讲改进有限，但是关键就是要开发写一个Dockerfile，这一点非常重要，意味着运行环境的配置提前到开发，而非直接交到运维，也即上面说的，开发5%的工作量增加减少大量运维工作，容器环境原子性升级回滚使得停服时间变短，可以保持开发、测试、运维环境的一致性。 [IMG] 模式四：使用Docker Swarm Mode 适用场景：发展中公司，中等规模集群 当集群规模超过50台时，裸用容器已经非常难受了，因为网络、存储、编排 服务发现等全部要靠自己的脚本或Ansible来搞定，是时候引入容器平台了。 当容器平台规模不是很大时，Docker Swarm Mode还是比较好用的： 集群的维护不需要Zookeeper，不需要Etcd，自己内置 命令行和Docker一样的，用起来顺手 服务发现和DNS是内置的 Docker Overlay网络是内置的 总之Docker帮你料理好了一切，你不用太关心细节，很容易就能够将集群运行起来。 而且可以通过docker命令，像在一台机器上使用容器一样使用集群上的容器，可以随时将容器当虚拟机来使用，这样对于中等规模集群，以及运维人员还是比较友好的。 当然内置的太多了也有缺点，就是不好定制化，不好Debug，不好干预。当你发现有一部分性能不行时，你需要改整个代码，全部重新编译，当社区更新了，合并分支是很头疼的事情。当出现问题时，由于Manager大包大揽干了很多活，不知道哪一步出错了，反正就是没有返回，停在那里，如果重启整个Manager，影响面又很大。 [IMG] 模式五：使用Marathon和Mesos 使用场景：万节点集群，多定制 当集群规模大一些，几百个节点时，很多人就不愿意使用Docker Swarm Mode了，很多的选择是既没有用DC/OS，也没有用Kubernetes，而是仅仅用了Marathon和Mesos。 因为Mesos是一个非常优秀的调度器，它的双层调度机制可以使得集群规模大很多。 Mesos的调度过程如图所示： [IMG] Mesos有Framework、Master、Agent、Executor、Task几部分组成。这里面有两层的Scheduler，一层在Master里面，allocator会将资源公平的分给每一个Framework，二层在Framework里面，Framework的scheduler将资源按规则分配给Task。 其它框架的调度器是直接面对整个集群，Mesos的优势在于，第一层调度先将整个Node分配给一个Framework，然后Framework的调度器面对的集群规模小很多，然后在里面进行二次调度，而且如果有多个Framework，例如有多个Marathon，则可以并行调度不冲突。 详细的调度机制非常复杂，可以看《号称了解mesos双层调度的你，先来回答下面这五个问题！》这篇文章。 而且Mesos的架构相对松耦合，有很多可以定制化的地方，从而运维人员可以根据自己的需要开发自己的模块。详细的定制方式看文章《定制化Mesos任务运行的几种方法》。 这也是很多优秀的公司使用Marathon和Mesos的原因。 例如爱奇艺、去哪儿、携程、当当等都选择了使用Mesos，需要提一下的是，大家如果参加社区，能发现裸用Marathon和Mesos的很多，但是整个DC/OS都用得比较少，而用Marathon和Mesos往往不能解决一些问题，因而这些IT能力非常强的互联网公司做了大量的自己的定制化，增加了Marathon和Mesos的外围模块。 模式六：使用开源Kubernetes 使用场景：千节点集群，少定制 Kubernetes模块划分得更细，模块比较多，比起裸Marathon和Mesos来讲功能丰富，而且模块之间完全的松耦合，可以非常方便地进行定制化。 [IMG] 而且Kubernetes的数据结构的设计层次比较细，非常符合微服务的设计思想。例如从容器->Pods->Deployment->Service，本来简单运行一个容器，被封装为这么多的层次，每次层有自己的作用，每一层都可以拆分和组合，这样带来一个很大的缺点，就是学习门槛高，为了简单运行一个容器，需要先学习一大堆的概念和编排规则。 但是当需要部署的业务越来越复杂时，场景越来越多时，你会发现Kubernetes这种细粒度设计的优雅，使得你能够根据自己的需要灵活的组合，而不会因为某个组件被封装好了，从而导致很难定制。例如对于Service来讲，除了提供内部服务之间的发现和相互访问外，还灵活设计了headless service，这使得很多游戏需要有状态的保持长连接有了很好的方式，另外访问外部服务时，例如数据库、缓存、headless service相当于一个DNS，使得配置外部服务简单很多。很多配置复杂的大型应用，更复杂的不在于服务之间的相互配置，可以有Spring Cloud或者Dubbo去解决，复杂的反而是外部服务的配置，不同的环境依赖不同的外部应用，External Name这个提供和很好的机制。 包括统一的监控cadvisor，统一的配置confgMap，都是构建一个微服务所必须的。 然而Kubernetes当前也有一个瓶颈——集群规模还不是多么大，官方说法是几千个节点，所以超大规模的集群，还是需要有很强的IT能力进行定制化，这个在模式七中会说一下我们在网易云上做的事情。但是对于中等规模的集群也足够了。 而且Kubernetes社区的热度，可以使得使用开源Kubernetes的公司能够很快地找到帮助，等待到新功能的开发和Bug的解决。 模式七：深入掌握使用Kubernetes 使用场景：万节点集群，IT能力强 随着Kubernetes使用规模的越来越大，大型的公司可以对Kubernetes进行一定的定制化，从而可以实现万节点甚至更大规模的支撑，当然需要IT能力比较强，网易在这方面有很多的实践。 从APIServer看集群的规模问题 随着集群规模的扩大，apiserver的压力越来越大。 [IMG] 因为所有的其他组件，例如Controller、Scheduler、客户端、Kubelet等都需要监听apiserver，来查看etcd里面的变化，从而执行一定的操作。 很多人都将容器和微服务联系起来，从Kubernetes的设计可以看出，Kubernetes的模块设计时非常的微服务化，每个进程都仅仅干自己的事情，而通过apiserver的松耦合关联起来。 而apiserver则很像微服务中的api网关，是一个无状态的服务，可以很好地弹性伸缩。 为了应对listwatch，apiserver用了watchcache来缓解压力，然而最终的瓶颈还是在etcd上。 最初用的是etcd2，这时候listwatch每次只能接受一个事件，所以压力很大。为了继续使用etcd2，则需要使用多个etcd2的集群来解决这个问题，通过不同的租户分配到不同的etcd2集群来分担压力。 将来会迁移到etcd3有了事件的批量推送，但是从etcd2到etcd3需要一定的迁移工作。 通过优化Scheduler解决并行调度的问题 大的资源池的调度也是一个很大的问题，因为同样一个资源只能被一个任务使用，如果并行调度，则存在两个并行的调度器同时认为某个资源空闲，于是同时将两个任务调度到同一台机器，结果出现竞争的情况。 为了租户隔离，不同的租户是不共享虚拟机的，这样不同的租户是可以参考Mesos机制进行并行调度的。因为不同的租户即便进行并行调度，也不会出现冲突的现象，每个租户不是在几万个节点中进行调度，而仅仅在属于这个租户的有限的节点中进行调度，大大提高了调度策略。 [IMG] 并且通过预过滤无空闲资源的Node，调整predicate算法进行预过滤，进一步减少调度规模。 通过优化Controller加快新任务的调度速度 [IMG] Kubernetes采用的是微服务常使用的基于事件的编程模型。 当有增量事件产生时，则controller根据事件进行添加、删除、更新等操作。 但基于事件模型的一个缺点是，总是通过delta进行事件触发，过了一段时间，就不知道是否同步了，因而需要周期性地Resync一下，保证全量的同步之后，然后再进行增量的事件处理。 然而问题来了，当Resync时，正好遇到一个新容器的创建，则所有的事件在一个队列里面，拖慢了新创建容器的速度。 通过保持多个队列，并且队列的优先级ADD优于Update优于Delete优于Sync，保证相应的实时性。 模式八：深入掌握使用DC/OS 使用场景：万节点集群，IT能力强 前面说过Mesos由于本身独特的调度机制，从而支撑的集群规模比较大，但是大多数使用Mesos的公司都没有使用DC/OS，而是裸使用Marathon和Mesos外加自己定制开发的一些组件。 Mesos可以支持当集群规模非常大，单个Marathon的性能不足以支撑时，可以使用自己的Framework机制，使得不同的租户使用单独的Marathon来解决问题。 [IMG] 后来DC/OS在最基础的Marathon和Mesos之上添加了很多的组件，如图所示，现在已经非常丰富，例如DCOS的客户端(kubectl)、API网关admin router(类似apiserver)、服务发现minuteman(类似kube-proxy)、Pod的支持、CNI插件的支持、存储插件的支持等，和Kubernetes已经非常像了。 很多公司裸用Marathon和Mesos而没有进一步使用DC/OS，可能是因为和核心组件Mesos已经经过大规模生产性支撑不同，这些外围的组件也是新的，对其稳定性也是有一定的顾虑，所以需要比较长的学习曲线，并且对于这些新的组件有非常好的把控，才敢上生产。 所以从这个角度来讲，虽然Mesos的稳定性和大规模无容置疑，但就整个DC/OS来讲，和Kubernetes从功能和稳定性来讲，在伯仲之间，都需要使用者有强大的IT能力，对于开源软件的各个模块非常熟悉，甚至能够做一定的代码修改和Bug fix，才敢在大规模集群中使用。 模式九：部署大数据，Kubernetes vs. Mesos Mesos还有一个优势，就是Mesos可以通过开发Framework，构建大数据平台，例如Spark就有基于Mesos的部署方式。 [IMG] 基于Mesos的Spark有两种方式，粗粒度和细粒度。 粗粒度模式（Coarse-grained Mode）：应用程序的各个任务正式运行之前，需要将运行环境中的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序运行结束后，回收这些资源。组粒度的方式浪费资源。 细粒度模式（Fine-grained Mode）：按需分配，应用程序启动时，先会启动executor，但每个executor占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务，之后，mesos会为每个executor动态分配资源，每分配一些，便可以运行一个新任务，单个Task运行完之后可以马上释放对应的资源。细粒度的缺点是性能有问题。 其实细粒度模式才是真正能够发挥Mesos动态资源调度最有效的方式，但是考虑到有大幅度的性能降低，[IMG]2.0.0被deprecated掉了。 如果使用kubernetes部署大数据，其实和部署一个普通的应用思路差不多，和Mesos不同，kubernetes不会干预到大数据运行的上下文中，Kubernetes启动的容器仅仅作为资源预留方式存在，容器内的资源分配则大数据平台自己解决。这样的利用率就降低了，相当于粗粒度模式。 基于容器部署大数据平台，也是建议部署计算部分，例如Map-Reduce，或者Spark，对于数据部分HDFS，应当另行部署。 模式十：容器和虚拟化混合部署 使用场景：大型公司，逐步容器化 对于很多大公司但是非互联网公司，使用容器还是需要小心对待的，因而需要逐步容器化，所以存在有IaaS平台，并且虚拟机和容器混合使用的状态，这种状态可能会持续相当长的时间。 在这种情况下，建议容器套在虚拟机里面使用。 使用Flannel和Calico都仅仅适用于裸机容器，而且仅仅用于容器之间的互通。 [IMG] 一旦有IaaS层，就会存在网络二次虚拟化的问题。 虚拟机之间的互联是需要通过一个虚拟网络的，例如vxlan的实现，而使用Flannel或者Calico相当于在虚拟机网络虚拟化的上面再做一次虚拟化，使得网络性能大幅度降低。 而且如果使用Flannel或者Calico，那容器内的应用和虚拟机上的应用相互通信时，则需要出容器平台，多使用node port，通过NAT的方式访问，或者通过外部负载均衡器的方式进行访问。在现实应用中，不可能一下子将所有的应用全部容器化，只是部分应用容器化，部分应用部署在虚拟机里面是常有的现象。然而通过NAT或者外部负载均衡器的方式，对应用的相互调用有侵入，使得应用不能像原来一样相互调用，尤其是当应用之间使用Dubbo或者SpringCloud这种服务发现机制时，尤其如此。 [IMG] 网易云开发了自己的NeteaseController，在监听到有新的Pod创建时，调用IaaS的API创建IaaS层的虚拟网卡，然后在虚拟机内部，通过调用Netease CNI插件将虚拟网卡添加到容器里面。添加技术用的就是上一节提到的setns命令。 [IMG] 通过这个图我们可以看出，容器的网卡是直接连接到虚拟私有网络的OVS上的，和虚拟机是一个平的二层网络，在OVS来看，容器和虚拟机是在同一个网络里面的。 这样一方面没有了二次虚拟化，只有OVS一层虚拟化。另外容器和虚拟机网络打平的好处是，当部分应用部署容器、虚拟机时，对应用没有侵入，应用原来如何相互访问，现在还是如何访问，有利于应用逐步容器化。 [IMG] OpenStack里面有一个项目Kuryr可以很好地去做这件事情，完全使用开源的OpenStack和Kubernetes可以尝试集成一下。 直播链接 [IMG]Kroah-Hartman，不知道的自己搜索。 一、一切从技术生命周期说起 任何技术，任何产品都是有生命周期的，如下图： [IMG] 都有起步，成长，成熟和衰退四个阶段： 起步阶段：也即一个技术的最初发明，这个时候，也许连最初发明产品的科学家都不知道此技术在市场上究竟如何使用，如何产品化。 成长阶段：此项技术被少数先知先觉的，有长远市场洞察力公司转化为产品，逐渐推向市场，被大众认可。此阶段，市场仍旧为蓝海，或因为技术壁垒，或因为市场不够成熟，竞争者较少，利润率较高，是先觉的公司快速增长，猛赚钱的阶段。 成熟阶段：此项技术或已经过了专利保护期，或已经被市场上的公司广泛掌握，技术壁垒已经基本消失。此阶段一般分为两个小的阶段： 第一阶段，大量的公司涌入，使得蓝海市场变为红海，利润率降低，可能产生价格战，称为群雄逐鹿的阶段； 第二阶段，少数公司经过良好的市场运作或消灭，或合并其他的公司，最后形成垄断，继续保持较高的利润率 衰退阶段：此项技术已经十分成熟，比较少有创新的空间，新技术的产生及代替作用使得利润率降低，哪怕是对垄断性的公司。掌握此项技术的公司已非明星企业，但是不会很快消亡，因为技术尚在使用，并且没有太多的公司进入，因而能够维持平稳的利润。比如虽然载人飞船已经上天了，马车仍在使用，制造马车的作坊也能实现盈利。 技术生命周期十分重要，对于任何一家技术公司来讲，能否把握好技术生命周期，能否在新技术的初期介入，在技术的衰退期成功退出，是公司成功与否的决定性因素。 然而成功把握好技术生命周期，不但要靠良好的技术创新，也要靠对市场的良好运作和把握。 然而技术和市场是矛盾的两个方面，因为技术部门是以技术为导向的，始终认为公司的产品是技术部门研发出来的，没有技术部门的成果，公司将不会存在。而市场部门则是以盈利为导向的，始终认为公司的产品是市场部门卖出的，公司的钱是市场部门一笔一笔带进公司的，研发部门是花钱的，没有市场部门，研发部门吃什么。 技术和市场的平衡，实在是企业的战略问题，能否掌握好这个平衡需要掌舵者既要有技术洞察力，又要有市场洞察力，是很多牛人都没有做好的事情。 我们会看到，对于尚处在起步和成长阶段的技术创业型公司，当最初的技术创业者仍然为CEO时，公司往往更加偏向于技术部门，技术部门的福利会比较好。然而当技术进入成熟阶段的群雄逐鹿阶段的时候，往往有的技术创业者难以胜任如此猛烈的市场竞争，或者CEO被换位更关注市场的市场人员，或者整个公司被其他善于市场运作的公司收购，从此刻开始，公司会偏向市场部门，技术部门的福利会逐渐减少，以适应市场运作和价格战。这也是为什么在研发人员看了很多技术非常好的公司反而被收购，然后大幅度降低福利的原因了。 然而开源力量正逐渐改变着技术生命周期的规律，开源之所以崛起，源于人类的分工的越来越细化，从细化到新技术的发明与应用脱离出一个人的能力，再细化到脱离出一个公司的能力，最终需要整个社会共同完成。 二、工业化时代，把牛的技术牢牢把控在自己手里，时间越长越好 在工业化时代到来之前，大牛们都是跨界的，能包揽数学家，物理学家，哲学家，天文学家为一人身上，社会分工和社会协作没那么重要。 工业化时代，社会协作已经非常普遍，很难像传统社会一样不相互协作，但是协作主要的方式是跨行业和领域，但是同一个垂直领域内的事情，只要技术足够好，一个大规模的企业是能够完成内部大规模协作的，所以企业规模会非常非常的大，人数会非常非常的多。 例如卡尔·本茨发明了内燃机车，从而有了奔驰，福特发明了流水线，从而有了福特公司，爱迪生创办通用电气等等。 三、信息化时代，最牛的干不过最兼容的 信息化时代，社会分工进一步细化和复杂，哪怕巨无霸之类的企业也没办法将一个垂直领域的事情在企业内部搞定，否则成本会非常高，产品会非常贵。 这个时候企业会有两种选择，一个是在技术初期形成技术壁垒，并保持这个技术壁垒，但是技术壁垒能够保持的时间越来越短，因为有的企业会做第二种选择，就是虽然技术不同，但是提供功能类似的产品，并一开始就保持兼容，这样使得整个行业和第一类企业进行PK，这样第一类企业抱在手里的技术不是是否能称为壁垒的问题，而是会被整个行业边缘化的问题，这样第一类的企业必须不断的创新，保持新的技术壁垒，而旧的行业已经因为兼容性，很快被卖成了白菜价，根本撑不起公司内部的合作。 例如在企业级服务器市场，IBM长期严格保护着自己在POWER微架构上的技术知识产权，开发了一整套从底层硬件、系统平台再到应用软件的垂直整合的封闭式堆栈。本来Power机器卖的非常的贵，IBM赚的盆满钵满的，但是还是迎来了x86开放平台的竞争。 首先，英特尔并不是x86处理器唯一的供应商，除了耳熟能详的AMD之外，还有多家供应商曾经涉足这一市场。x86指令集是一个比较开放的指令集，包括英特尔、AMD在内的供应商之间，长期以来通过交叉授权指令集的方式，构成了相对RISC架构更为开放的x86架构。但最重要的原因还是体现在操作系统和应用软件上，以英特尔为代表的x86处理器供应商，在一开始就致力于兼容、支持更多的操作系统和应用软件，比如说在操作系统领域，Windows、Linux自不必说，VMware的vSphere也是依靠x86服务器平台而发展起来的。 于是后来康柏，惠普，戴尔，联想，浪潮都把X86服务器卖成了白菜价，利润率大幅降低。 同样在个人电脑领域，在巨头们都没有在意这个市场的时候，苹果公司率先推出了苹果个人电脑，受到了市场的巨大欢迎，然而随着兼容器的大量涌入市场，个人电脑的成本越来越低，到现在买个笔记本电脑也和买个白菜差不多了。 从硬件到软件都做的苹果公司在成本上肯定要高于纯粹的兼容机生产商，虽然苹果粉们无无限热爱MAC个人电脑，但是仅仅靠个人电脑部分无法撑起整个苹果帝国，所以苹果必须快速打造下一个创新点，也就是大家众所周知的移动设备领域的苹果手机。 然而后来有了移动领域的开源操作系统安卓，于是移动设备领域又出现了个人电脑领域同样的一幕，所有其他的厂商借着开源操作系统杀了进来，价格越来越低，已经几乎人手一部的节奏。苹果公司借着先发优势，良好的用户体验，仍然活的非常爽，但不能不说同样危急四伏。可以想象在开源的领域，有一部分人会进一步降低手机的价格，有一部分人会进一步增强手机的性能，还有一部分人不断的增强用户体验(例如罗永浩)，苹果需要赶快开启下一个新的创新点，开启新的技术生命周期，而不能仅仅限于屏幕变大些，系统变快些的小改动。 三、互联网时代，开源对技术生命周期进行彻底的冲击 互联网时代，分工已经如此的细，细到一个专家只能专注于某个非常非常细分的领域，就像图灵奖获得者姚期智的成就为创建理论计算机科学的重要次领域：通讯复杂性和伪随机数生成计算理论，大家不用理解这是什么，但从名称已经可以看出比《自然哲学的数学原理》细分了N多倍。 从事计算机软件的人可能更加的清楚，从计算机语言几十种，到从事的领域(通信，ERP，搜索，视频等等上百种)，不同的框架(上千种)等等千差外别，不一而足，分的不能再细了。 好在有互联网，可以将如此多细分的领域通过网络的链接起来，进行自由协作，在这个时代，我们发现技术生命周期不管用了。 企业和组织很难抱着一个封闭的技术，通过法律的保护，过几年高利润的生活，因为任何的创新都会飞快的在组织外进行复制，不是偷你的知识产权，不是偷你的代码，你不用把门禁系统搞的这么严，没用的，只要你的产品出来了，这个形态市场喜欢，开源软件的大牛们就能够根据这个思想，通过互联网的相互协作，组织起比你的公司更多的力量，重新快速的写一套代码，可能很快更加稳定，应用范围更广，会有大批的企业用这个开源软件开发出新的产品，很快就能把这个产品干成白菜价，知识产权保护不了你多久，就能够普惠大众。 我们能够发现无论是那种技术的普及，都离不开三种牛人的馈赠： 第一类大牛：产品和技术的创意者。 世上本没有某种东西，是这些大牛有独特的产品的思维，或者技术的能力，创造出了某种东西。例如苹果的智能机操作系统IOS，Google的分布式文件系统GFS，搜索引擎，Oracle数据库，Vmware虚拟化软件等。 这些产品和技术改变了世界，带来了便利，自然应该取得商业上的回报，赚的盆满钵满。在这个阶段，虽然站在岸边看着的公司和技术人员看着别人数钱数到手抽筋，却只能眼巴巴的看着，没有办法，大家都在等待第二类大牛的出现。 第二类大牛：开源软件的实现者。 这个世界上还是有很多有情怀的人的，尤其是程序员里面，有情怀的人喜欢做一件什么事情呢？开源。这个世界上很多软件都是有闭源就有开源，源就是源代码。就是说某个软件做的好，所有人都爱用，这个软件的代码呢，我封闭起来只有我公司知道，其他人不知道，如果其他人想用这个软件，就要付我钱，这就叫闭源。但是世界上总有一些大牛看不惯钱都让一家赚了去。大牛们觉得，这个技术你会我也会，你能开发出来，我也能，我开发出来就是不收钱，把代码拿出来分享给大家，全世界谁用都可以，所有的人都可以享受到好处，这个叫做开源。 在上个阶段大部分平庸的公司和技术人员眼巴巴的看着创意者赚钱的时候，大牛们早就开始动手了，这些大牛书写开源软件的速度超出人们的想象，初期的代码往往直接和略带混乱，于是有了Android，Hadoop，Lucene，Mysql，OpenStack等。 如果不是有开源技术的大牛，如我们普通的技术人员还不知道要等多久。 然而一旦开源技术出现，马上就会有大量的厂商带领着大量的普通技术人员涌入，基于开源软件迅速封装自己的产品，并以低价杀入市场，打破原来创意者躺着赚钱的美梦。在开源软件领域，从大批公司疯了一样的做搜索引擎，底层大部分使用lucene，后来又有大批公司做大数据，底层大部分用hadoop，后来的OpenStack热，Docker热，都是开源大牛带给世界的红利。 不要以为将开源软件封装为产品很简单，在大家的技术栈几乎相同的情况下，能够杀出一条血路，也是非常牛的。 第三类大牛：开源产品的经营者。 当技术都差不多的时候，能活下来的公司的经营者，所需要的综合素质比前两种牛人一点都不低，简直是十八班武艺样样精通，如何在开源软件的基础上开发出有差异的产品，产品需要上市速度快并且用户体验好，要能认准一个此类技术最试用的行业迅速杀进去占领市场，要能留得住开源领域内的大牛，要能够控制好公司的成本，要能够在这轮钱烧完之前做出成绩融到下一轮。最终大浪淘沙留下来的都是牛人，也正是因为他们，相应的技术才能够以白菜价被大众使用，普通人和公司才能买的起。 四、未来，开源会使企业的主动选择 以后互联网软件的方式，是企业会主动选择开源，只有尽早开源，拥抱开源，才能更多的主导开源的江湖，而不被边缘化，反而只有更早的开源，才能保持自己的技术优势。 在云计算领域很多人都知道CloudStack和OpenStack的故事，两个功能几乎类似的云计算软件，CloudStack甚至都比OpenStack成熟N多倍，但是因为CloudStack开源的时间晚了一点点，并且被少数的公司主导，而使得OpenStack迅速发展壮大，所有如雷贯耳的公司都加入到OpenStack社区里面来，OpenStack已经成为开源云计算的事实标准，Vmware也开始对其进行兼容，大批企业的涌入很快将云计算基础设施干成了白菜价。 再后来，如Docker，DC/OS, kubernetes，tensorflow等，都是尽早开源的，都是在创立这个技术的公司还没有用这个技术赚到钱就开源了，以后的差别可能不再是软件代码本身，而是数据和服务。 开源是互联网时代个人力量的崛起，GitHub的伟大不仅仅是代码的管理工具，而是聚合程序员的力量，程序员是改变世界的人群，在人工智能时代，他们的代码会控制着社会的方方面面。 最后上几张LC3的图 [IMG] [IMG] |