您好，欢迎来到！
当前位置：&>&&>&如何在生产环境运行容器
如何在生产环境运行容器
13:51:31&&
人气：223次&&评论(0)
所属标签：
　　Vivek Juneja是一名工作首尔的云服务工程师。他从2008年就开始接触云服务，是最早的AWS和Eucalyptus的使用者。本文中总结了在生产环境中使用容器的几个方面，特别是对虚拟机与容器的混合部署的观点很值得推荐给大家。　　　　如果只是把容器限制在开发测试环境中，那么您并没有享受到面向容器研发和发布工作的全部红利。对在生产环境中使用容器的抵触情绪来源于对安全与隔离性的担忧，同时也包括对管理容器的运维经验的缺乏。　　　　在不同程度上使用容器的组织中，迁移这些容器到生产环境的决定是需要非常大的决心的。而为全新的系统和应用采用容器技术就会轻松许多，这些系统是完美的容器原生系统。　　　　容器原生是什么概念？一个容器原生的应用被设计和构建在容器的生命周期内，并将容器视为第一等公民。对于那些为了适应容器而被改造的应用，迁移到生产环境的决定通常是很难下的。这里是指那些遗留应用，这类应用如果要选择容器化的开发与发布模式，更是需要大范围的改造。　　　　理解在生产环境运行容器对现有工作流程的影响是非常有必要的。下面列举了一些可能受容器影响的工作流程：　　　　将改进或新功能从开发环境发布到生产环境　　　　允许终端用户访问生产环境中的改进或新功能　　　　在生产环境中定位问题　　　　监控生产环境中的应用　　　　升级生产环境中的应用　　　　数据备份　　　　容灾和业务延续　　　　生产环境容量规划　　　　主机设置，特别是网络和安全设置　　　　容量规划　　　　在容器选型的组织中不使用容器运营生产环境是比较常见的。在这样的组织中，虚拟机作为发布单元，承担了应用隔离和管理的职能。极有可能的，这些独立的应用分布在一组虚拟机中，这些虚拟机为了高可用有多个副本分布在许多主机中。如果同一个生产环境被不同应用所共享，那么虚拟机就是做系统隔离的一把利器。　　　　运维团队负责虚拟的整个生命周期，应用代码通常使用自动或人工工作流程拷贝到虚拟机中。虚拟机很少因为新的发布而被销毁，相反虚拟机只是用新版本的代码来进行发布。这些虚拟机偶尔的发生变化，变化是通过使用新版本的经典镜像来重建虚拟机。　　　　另一方面，一些组织实践在发布更新时作废老虚拟机，再重新生成新的虚拟机。Netflix的Aminator(/Netflix/aminator) 和围绕它周围的实践已经成为如何用虚拟机管理生产环境并实践不变性的一股潮流。　　　　容器的支持者们持续的宣传使用裸机来运行容器化应用。这可以避免从主机与操作系统连接层产生的性能和上下文切换的代价。这个建议在我们运行不与其他非信任系统共享资源的单体应用时会显得更加有必要。　　　　一般组织在早期做容器选型时会使用混合策略来处理这种情况：组合运行在虚拟机和裸机中的容器化应用。这种组合可以通过分析管理和性能指标后进行调优。当运维容器的成熟度达到一定阶段后，这些组织会采用在裸机上运行他们的应用。　　　　在共享的生产设施中运行多个应用时，在裸机中运行容器的决定需要依靠先前的经验。一个较为安全的选项是将不同的租户用虚拟机包装起来，让容器在这些虚拟机的内部作为你的服务的运行时环境。每个部署容器的虚拟机属于相同的租户，这样就在不同的租户之间提供了隔离性。　　　　图一：在成熟度低的时候，租户之间不会共享生产环境。可以使用虚拟机或者物理机进行隔离。在成熟度高的时候，每个租户的应用组件被扩散到共享的设施中。作为容器来说，高成熟度代表着每个租户的应用组件被扩散到共享的虚拟机或者裸机的设施中。　　　　在生产环境中发布应用　　　　容器的临时天性使得升级应用时应该使用全新的容器发布程序变更，而不是去更新已经存在的实例。当一个特定的修改被标记为需要发布到生产环境时，一组使用新版本的镜像被创建出来，新的容器被新的标签标记。新标签最后是使用持续集成工具创建的。生成出来的镜像和标签被存储到容器镜像注册中心内，那里可被生产环境访问。　　　　相比于容器注册中心在所有环境中被共享-包括开发，测试和生产环境-在某些情况下，为生产环境使用单独的容器镜像注册中心是合理的。单独的生产环境容器镜像注册中心不会与其他环境共享。在这种情况下，需要一个较好的工作流程将开发和测试环境中的候选的容器镜像迁移到生产环境中。一个中间系统将会从开发/测试注册中心拉取候选的镜像，然后重新标记而后推送到生产环境的注册中心内。使用这个方法，将会在其他环境和生产环境之间的容器镜像产生清晰的隔离。　　　　容器的临时特性极大的限制了原有的运维经验，那就是使用静态端口绑定和IP地址来发布主机中的应用。这种静态手段对于配置网络防火墙和交换机是有帮助的。在生产环境中发布更新的最佳实践是去选用滚动更新。这就要求在生产环境中部署额外的设施去修改已经存在的负载均衡器和代理的配置，当一组新的容器实例启动现有版本。　　　　为了在发布容器的时候保持一定的可恢复性，非常明智的做法是使用编排工具来管理容器运行环境。如果不使用任何编排工具，那么运行时配置策略，比如&--restart&，就是非常必要的。推荐的重启策略是在&on-failure&和&unless-stopped&之间切换，或者根据你的环境从中选择一个。　　　　在生产环境中为容器设置主机环境　　　　在你为容器准备生产设施时一个重要的考虑关键点是了解容器镜像的“密封”特性。容器镜像需要一套标准化的设施用以保障在开发，测试和生产环境的配置是相同的。这套标准化设施可以严格保障在生产环境中得到符合预期的行为。以下是需要考虑的要点：　　　　内核的选择　　　　容器运行时版本的选择　　　　网络访问与防火墙配置　　　　安全加固方案的选择　　　　系统访问权限　　　　虽然背离以上要素的一部分是很有诱惑性的，但是任何改变都会带来意想不到的结果，所以需要认真衡量这些改变。解决这个问题最简单的方法是从开发，测试到生产的所有环境都保持相同。一开始这点是很难做到的，但是考虑你选择容器的终极目标是什么后，你会说服自己的。所有的环境使用相同的Linux内核；它们使用相同的主机配置，文件系统拓扑，网络配置和用户角色。标准化所有的元素帮助你去保证容器镜像在被构建和测试后一直到生产环境均保持相同。　　　　容器运行时的某些方面的行为是会有些不同的，比如访问其他依赖应有的URL或者日志级别。这些运行时配置可以通过一些手段传递给容器。其中一种是通过环境变量将运行时配置注入到容器实例中。这些环境变量指向服务注册中心，那些注册中心包含了正确的依赖服务。诸如ZooKeeper和Consul这样的工具对于实现这种操作是有帮助的。　　　　如果主机已经使用了配置管理工具，比如Chef，Puppet和Ansible，那么最好是在所有环境中尽可能使用单一的配置。对于可扩展的设施来说，考虑到可用性和性能的要求，在所有环境中不同的配置应该只是实例的数量。　　　　主机需要偶尔的升级到最新的内核分支或容器版本等。这些升级不能被封装在容器镜像中。这些对主机配置的修改应该遵循滚动升级的原则，那就是进行阶段性升级，而不是做一次全量升级。　　　　最后，像主机一样，支援设施的配置也应该保持相似，比如日志聚合系统，监控，度量，服务路由和发现系统。这其实是要求与容器镜像有关的系统，不仅仅是主机，而且包括在环境中所有参与的系统，都需要有一定层次的一致性。　　　　在生产环境中的容器服务发现　　　　对于容器化应用来说标准化服务发现机制是一个重要的考量点。运行容器化应用的方式与运行虚拟机内应用的方式很少是一致的：那是因为在一台主机内会运行超过一个的容器。在这个极其罕见的情况下，如果你使用桥接网络模式，你可以为你的每个容器使用静态端口。这意味着你对主机中的容器预先选择了需要暴露的端口，并使用这些端口去配置负载均衡器和代理。　　　　重配负载均衡和代理可能是不需要的，如果对在主机中增加容器仅仅是有限的需求。但是在大多数情况下，容器的增减是基于对稳定部署的负载或者扩展实践的思考，并且那是服务发现系统发挥作用的地方。　　　　生产环境支持：日志搜集和监控　　　　在生产环境中容器对于支援服务的需要与非容器环境是一样的。这包括了如何从容器实例中捕获日志并将它们传输到集中化日志管理系统中。内建的日志后端已经在Docker守护进程中得到了支持，并且现在有一些个性化的解决方案也可以使用。　　　　目前有许多管理Docker容器产生日志的手段。Docker的默认设置是将日志非压缩的写入到磁盘中，并且可以选择删除策略去限制日志占用的磁盘空间。在生产环境中，有许多日志驱动与Docker引擎协同工作并提供给产生日志的应用许多灵活方案去透明化管理日志。如果你已经使用了一种集中化日志管理解决方案，那么你可以选择一种Dokcer日志驱动来向它填充日志数据。日志驱动支持许多种协议，比如Syslog，它可以被用在许多内嵌系统中或者云化的SaaS方案中。　　　　容器的临时状态在容器的日志和监控领域是需要被强调的一个关键特性。在生产环境做发布时，新容器会替换掉老的。这对于传统概念中假设有状态和长时间运行的计算单元是一种破坏。滚动容器特性对于传统日志和监控理念带来了新的问题。与让计算实例运行长达数天甚至数月不同，容器可能在以小时为窗口的时间内就发生变化。　　　　如果你实践持续化集成，这个窗口可能更小。一个以主机维度构建的日志和监控解决方案不能适应容器的灵活性。由于容器短暂的生命周期，几乎不能有一个预先说明的方式去监控它们。并且最后是将它们作为一个群组去监控，而不是监控每个容器。　　　　将容器归为一组的一种方法是使用合理的元数据，比如标签。一个标签指的是“镜像标签”，它可以在生产环境中被运行。不要使用令人困惑的“最新”标签。　　　　举例，假如你发布了一个叫做“product-api”的应用，并使用镜像标签“25”，环境变量设置位“production”。这意味着这是被构建系统第25个标记的镜像，并且容器运行在生产环境中。你可能在给定的时间上在容器设施中运行了很多这种实例。标签在新的发布时会被改变，但是环境变量配置将会保持为“production”　　　　监控系统将会监控环境变量被设置为“production”的容器镜像，就好像监控一个长时间运行的生产服务一样，这样就避免了发布新版本带来的持续更新的问题。如果你使用编排工具，你应该使用更有表达力的标签来编组你得容器实例。　　　　容器生产环境中较为合理的监控和日志策略是使用非侵入解决方案，这样就与运行时容器进行了隔离。容器监控工具需要容器感知，甚至容器平台感知。这种感知能力将会帮助监控工具在报告错误时避免错乱，例如当容器在一台主机中停止的时候并被容器平台迁移到另外一台主机。容器的足迹导致一些而外的数据需要被监控和被日志系统搜集，因此产生了额外的数据需要管理。　　　　容器监控是一个飞速发展的领域，我们会在今年晚些时候发布第五部电子书中详细介绍这部分内容。目前有一些SaaS服务和本地化工具来帮助你应对该领域中的问题。　　　　管理容器数据的方法　　　　目前被广发接受的管理容器数据的方案是在生产环境中使用无状态的容器，这些容器不会在其内部储存任何数据，也就是完全事务性的容器。无状态容器在外部储存处理过的数据，超过容器范围的数据，更可取的方法是使用合适的存储服务作为可靠并可用的持久化后端。安全性在存储服务中是被更加重视的，比如数据库，队列和缓存服务。对于这些有状态容器，可接受的模式是使用数据容器。有状态服务的运行时引擎在运行态时与数据容器链接。在实践中，这意味着数据库引擎运行在一个容器中，但是“数据容器”被挂在为卷轴来存储状态。　　　　如果你使用编排平台来运行一组主机环境，那么使用分布式存储方案是非常有必要的，比如Cluster和Ceph，他们提供了共享挂载点。如果容器实例基于可用性原则在集群中来回移动，这些方案是非常有用的。　　　　容器安全与密钥管理　　　　安全是经常让你担心的，尤其当不同租户的多个容器实例运行在共享的机器中时。这种担心来源于对容器技术能否提供良好的隔离性的信心的缺失，这种期待来源于虚拟机技术的实现。但是，把容器作为虚拟机的替代者并不能改善这种担心。容器的实现，例如Docker，对应用提供安全包装。容器运行态抽象了在不同命名空间配置细粒度权限的复杂性，比如用户，网络和进程。　　　　如果考虑到在共享设施中一个容器的多租户发布过程，使用虚拟机来隔离不同的租户，并且使用容器来隔离一个租户的不同应用组件。当社区中容器发布持续增长时，那么就需要去掉虚拟机的隔离，让所有用户共享相同的设施。　　　　运行一个不变容器实例需要考虑的另外一个要点是避免将需要保证安全的密钥和证书暴露出去。现在有很多方法来解决方这个问题，从将密码通过环境变量设置，到挂载加密数据容器为卷轴来保护它们。但是，在这些技术中还是又很大隐患，并且从容器运行提供者那里没有可用的标准方案。　　　　生产环境容器化展望　　　　成功将容器应用于生产环境的一个重要的条件是建立良好的社区。工具和实践持续发布，直到在大多数组织中运行容器变成一个常规的选项。在此之前，这种适应容器的战争在组织内部不会完结。使所有的利益相关者，特别是运维和安全团队，深刻的认识到他们对于容器的要求是需要很多工作才能实现的。在生产环境中使用容器和使用虚拟机是非常不同的，并且它将优先需要的是开发经验和运维简化，除了资源利用率的好处外。
热门活动：
阅读:223次
网友评论&登录后发表评论，让更多网友认识您！966,690 十一月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
阿里李纯：从架构师到CTO，成长没有一蹴而就
阿里李纯：从架构师到CTO，成长没有一蹴而就
Author Contacted
相关厂商内容
相关赞助商
更多AWS最新精彩内容和活动，！
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
学到了很多
Very nice post !
Re: Very nice post !
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。【连载】PayPal黑帮是如何一统硅谷的（三）
作者：Xtecher 微信公众号
埃隆马斯克闪电般登场，又闪电般离开，彼得蒂尔接任 CEO，他采取了新的策略让95%的目标卖家升级成了付费用户。这场硅谷宫斗大剧正式收官，PayPal 势力大获全胜，X.com 从此湮没在历史。埃隆马斯克出乎意料的接受了这一事实，并且其后还在 PayPal 的融资过程中追加了个人投资，展现了极高的个人格局。Xtecher特别连载 作者：神策数据CEO 桑文锋 网址： 微信公众号ID：Xtecher烧钱问题虽然在 2000 年的 4 月初融了 1 亿美元，但是公司运营支出的很快，差不多每个月 1000 万美元，也就是用不了一年，钱就会被烧光了。这其中每天用于给新用户注册奖励、支付信用卡公司手续费和诈骗损失，就有 15 万美元，每个月就有 450 万美元。所以改变烧钱的模式，是当时最急需解决的问题。上篇提到埃隆马斯克上台后采取的两个措施，一是增加企业付费账户，二是促使用户采用借记卡而非信用卡以减少手续费。这两个措施只能说是开了个头，但落地效果还没有特别体现出来。在拍脑袋决定信用卡支付限额的事件发生之后，产品团队想到了新的主意来提升企业付费账户的比例。因为承诺永远不会强制用户升级为企业账户，所以需要采用一些更合理的方式来推进这一步骤。在 PayPal 系统最开始设计时，为了减少实现的代价，可以说是许多数据都没有被记录。比如 eBay 交易详情，没有这些信息，就很难定义用户是在进行商业行为，也就是把账户定性为企业账户。有成员提出可以限制每个月可以免费收到 30 笔付款，或者每天可以免费收到 1 笔付款，但这没有太多的依据，还是拍脑袋的提议。为此，他们对数据库中的支付记录进行了数据分析。发现每半年接收超过 500 美元信用卡支付的卖家，共有 10 万名，他们覆盖了 3/4 的交易额。剩下的 300 万名普通用户，并不需要包含在内。这样就可以限制推动升级的比例，减少大多数用户的抵触情绪。可这一思路根本就没来得及实施，埃隆马斯克让团队投入到另一件事情上了。2.0 和 PayPal 品牌 PayPal 在开始设计时，为了能够快速上线，在架构上只能支持 350 万用户。随着用户量的增长，在 2000 年 6 月份已经达到了 210 万，并且以每天 1 万名新用户的速度进行增长，也就是到 9 月份，就要达到上限了。用户量的增长，随之而来的是交易量的增长，这给服务带来了巨大压力。埃隆马斯克要求团队快速推进 PayPal 2.0 的研发工作。?▲（图1 注册用户数和日交易额）在两家公司合并之前，PayPal 团队是采用 Unix 进行系统开发的，而 X.com 是采用 Windows NT 的，对于 PayPal 2.0，CTO 拉夫琴坚持用 Unix，而埃隆马斯克拍板要用 Windows NT。我从埃隆马斯克在 2007 年的采访中了解到，他当时的考虑是 Unix 在那个时候开发工具不够完善。而 Windows NT 更为成熟，微软提供的开发工具使工作效率更高。可原 PayPal 的工程师切换到 Windows 开发还是有一定学习代价的，再加上思想上比较抵触，因而进展比较缓慢。为了加速 PayPal 2.0 的研发进度，埃隆马斯克要求停止所有新功能的升级，不然 PayPal 2.0 上也要同步增加同样的功能，这就没有了结束的时候。并且为了激励大家，承诺只要在 9 月 15 日之前顺利上线，每人奖励 1 万美元，延期 1 天，则减少 1000 美元。可这么大的诱惑，还是没有能让项目顺利完成，项目的延期直接导致团队的士气低迷。还有一件事让冲突最终不可调和。在埃隆马斯克上台之后，就想要逐步去除掉 PayPal 这一品牌，统一用 X.com 来代替。据说埃隆马斯克当年是用 100 万美元买的这一域名，并且觉得这是最好记的一个域名。可 PayPal 由于推出的较早并且体验好，已经成了一个深受用户喜爱的品牌，就像现在我们说“有问题Google / 百度 一下”一样，eBay 上的用户会说“把钱 PayPal 给我”。在 9 月份悉尼奥运会召开时，埃隆马斯克给自己放了两周的假期，和妻子去悉尼补个蜜月。在临走时，交代产品经理要将 PayPal 品牌名全线移除。这可让 PayPal 的原员工们接受不了，他们发起了一次用户调查，抽取了几千名用户来反馈对两个品牌名的认可度，结果是 PayPal 有绝对优势。不巧的是，埃隆马斯克也是随机抽取的用户之一。这让他大为恼火，一通通的电话一封封的邮件，坚持移除工作继续。埃隆马斯克下台产品副总裁戴维萨克斯发动了一次叫“PayPal 复兴”的行动。他召集大家对弹劾埃隆马斯克进行签名，就是如果不撤销埃隆马斯克的 CEO 职位，就选择集体辞职。其中拉夫琴领导的工程师团队几乎全部都签名了。经过和董事会的沟通和讨论决议，埃隆马斯克被赶下了 CEO 的位置，彼得蒂尔接任了临时 CEO。▲ Peter thiel彼得蒂尔上台后，停止了 PayPal 2.0 的研发工作，继续保持 PayPal 的品牌名，并且在几个月后，连公司名字都从 X.com 改为了 PayPal。按照我们一般所看到的国内的故事，这种情况下，被赶走的一个绝对是要大闹一番，鱼死网破。但埃隆马斯克接受了这一事实，并且在后续的融资中，还增加了个人投资，这充分体现了埃隆马斯克的个人境界。彼得蒂尔一方面要让暂停的产品迭代迅速开展，另一方面还要迎接来自外部的挑战。提升营收彼得蒂尔上台以后，立即停止了 PayPal 2.0 的开发，并且停止了金融超市服务。在 PayPal 和 X.com 最开始合并时，公司的思路是将 PayPal 的网络支付功能用于吸引新用户注册，然后引导用户使用金融超市服务，比如购买基金或进行信用贷款，来获取营收。经过这几个月的挣扎，现在 PayPal 彻底放弃了金融超市的思路，把网络支付作为主业务。这其实在埃隆马斯克上台之后就这样转型了，只是现在更加彻底。▲ Paypal早期成员合影既然不用开发 PayPal 2.0 了，增加营收的改进就可以继续了。在上篇提到通过数据分析发现，每半年 500 美元的免费收款限额是个理想的选择，于是迅速在功能上体现。如果一个卖家半年内接收的信用卡付款超过 500 美元，则超出部分会进入“待定”状态。卖家只有升级到付费版，才能接收到这些钱，否则，钱将退还给用户。这一方案推出后，引起了一部分卖家抱怨，但不到一个月的时间，95% 的目标卖家都升级到了付费版，真是一次成功的策略。加上将用户每半年信用卡支付的限额从 2000 美元降低到 250 美元，两者叠加的效果就是 大部分的交易可以收取 2% 的手续费。相比以前的 -2.5%，这真是巨大的转变。反诈骗之战有些不法分子盗取信用卡，然后批量注册 PayPal 帐号，绑定这些信用卡。再将信用卡支付给指定的账户，这些账户再把钱取出来。信用卡机构发现后，会让 PayPal 赔偿。这样的损失达到了交易额的 1.21%。尽管麦克斯拉夫琴给埃隆马斯克提出过，但后者没太当回事。现在，这个问题也可以考虑解决了。他们通过数据去分析这些诈骗分子的交易特征，其实还是比较有规律的。比如都是新创建的帐号，并且向同一批帐号支付，并且支付金额、使用频率都有一定的规律，那就可以把这一批关联的帐号锁定，然后由人工进行审核。他们甚至还帮助联邦调查局抓捕了两个俄罗斯诈骗分子。他们积累的这些技术经验，后来都用到了一家创业公司，就是神秘的 Palantir。为了阻止程序自动注册帐号，技术人员想到了一个主意。他们生成一些图片，图片上印有扭曲的字母，并且有一些背景划痕，人是可以识别这些字母的，但是机器很难识别，这样自动注册行不通了。现在这种图像识别码的方式已经非常普及甚至到了滥用的地步，但其实最早是 PayPal 发明的，至少是最早商用的。通过这两个措施，诈骗损失从交易额的 1.21%，降到了 0.48%。直接导致诈骗分子们跑到竞品上作案。说到竞品，身在中国的你肯定会好奇 eBay 怎么自己不提供支付，就像淘宝网有支付宝一样。eBay 最开始的买卖双方支付，靠的是邮寄支票之类的，交易周期很长。在 1999 年中，eBay 收购了一家信用卡支付公司 Billpoint，并在 2000 年 3 月 1 日，正式开始对外测试自己的支付服务。说来 Billpoint 有主场优势，按理说根本不会有 PayPal 的机会，那两者的竞争是经历了怎么一个过程呢？天空一声巨响，彼得闪亮登场，原来彼得和埃隆还有这种老梗。PayPal 与 X.com 铸剑为犁，然而他们却遇到了新问题，面对 eBay 原住民 Billpoint ，他们将何去何从？请继续关注Xtecher：），我们将在下周六继续 PayPal 黑帮发迹史的连载。点击图片阅读推荐文章PayPal黑帮系列连载 ：【连载】PayPal黑帮是如何一统硅谷的（二）【连载】PayPal黑帮是如何一统硅谷的（一）本文作者人物特稿：《神策数据桑文锋：我对“灵光一闪”没有兴趣》| 推荐阅读 | 点击文字直接跳转精品文章：Xtecher人物特稿人工智能出门问问李志飞：AI创业者的孤独驭势科技吴甘沙：我的根本利益格灵深瞳赵勇：把未来一个齿轮一个齿轮地变成现实地平线方懿：告别诺基亚后，我终于找到了下一个足以与手机媲美的市场虚拟现实诺亦腾戴若犁：越来越好奇，越来越好奇大朋VR陈朝阳：朴实的终极梦想Ximmerse贺杰：VR的远方有多远？Pico周宏伟：用“善良”去做一件美好的VR产品焰火工坊娄池：没有比我更狡猾的创业者其他科技创业者Ping++金亦冶：所有你走过的捷径，总有一天都会再绕回来神策数据桑文锋：我对“灵光一闪”没有兴趣墨刀张元一：一位全栈工程师的星辰大海海云数据冯一村：此时此刻，给大数据一个注视将门高欣欣：送创业项目一个里程碑事件佳格数据张弓：从NASA走出的“理性疯子”，他志在耕耘天地间诸葛io孔淼：在我还不知道代码是什么的时候，我只想写诗奇点机智宋嘉伟：一个从容的创业者是如何思考瀚诺半导体张诚：十年的北大研发路，只为这一款千兆芯片彩云天气袁行远：无论晴雨，步履不停Vinci宋斯纯：历历万乡，不负每一场如果你拥有高精尖科技创业项目，Xtecher将为你提供：1.专业的科技人物特稿和视频拍摄2.在Xtecher官网、APP、微信的全方位展示3.最专业的科技圈投资人、政府资源、产业资源4.创业企业品牌管家与PR服务请关注本微信公众号：Xtecher，即可联系我们。微信号：Xtecher关注未来的人都关注了Xtecher动动小手指，进入Xtecher，查看科技项目详情！▼
相关微信文章：
相关推荐：
本网站所有内容均采集自网络，如有侵权麻烦邮箱联系删除。