PaaS

一天天的,PaaS深入人心，Cloud Foundry为首的传统PaaS，开始蓄力基础设施领域的 平台化 和 PaaS化 ,于是发现了PaaS中的问题 1 如何给应用打包 Cloud Foundry/OpenShift/Clodify都没给出答案，走向碎片化歪路 此时，名不见经传的PaaS创业公司dotCloud，却选择了开源自研的容器项目 Docker 谁也不会料到,就这样一个平淡无奇古天乐一般的技术，开启了名为“Docker”的新时代 这个🐳公司，最重要的战略之一就是：坚持把**“开发者”群体放在至高无上的位置** Docker项目的推广策略从一开始就呈现出一副“憨态可掬”的亲人姿态，把每一位后端技术人员（而不是资本家）作为主要的传播对象。 简洁的UI，有趣的demo，“1分钟部署一个WordPress网站”“3分钟部署一个Nginx集群”，这种同开发者之间与生俱来的亲近关系，使Docker项目迅速成为了全世界会议上最受追捧的新星 > Docker项目，给后端开发者提供了走向聚光灯的机会 > 比如Cgroups和Namespace这种已经存在多年却很少被人们关心的特性，在2014年和2015年竟然频繁入选各大技术会议的分享议题，就因为听众们想要知道Docker这个东西到底是怎么一回事儿。 一方面解决了应用打包和发布这一困扰运维人员多年的技术难题 另一方面

Cloud Native（云原生）是以云架构为优先的应用开发模式。目前，越来越多的企业已经在大规模开始拥抱云，在云环境开发应用、部署应用、发布应用。未来，越来越多的开发者也将采用 Cloud Native 来开发应用。本书是国内第一本 Java 领域 Cloud Native 著作。 那么为什么Cloud Native模式会越来越流行？Cloud Native与微服务有什么区别？何时选择使用Cloud Native？等等，这些问题将在本文一一解答。 什么是 Cloud Native Cloud Native （国内译为“云原生”），最早是 Matt Stine 提出的一个概念。与微服务一样，Cloud Native 并不是一种具体的技术，而是一类思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native 既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。所以，Cloud Native 也可以说是一系列Cloud技术、企业管理方法的集合。 Cloud Native 具备有以下特性： 以云为基础架构 云服务 无服务 可扩展 高可用

云加社区技术沙龙 发表于 腾讯云技术沙龙 订阅 56 干货满满，腾讯云+社区技术沙龙 Kafka Meetup 深圳站圆满结束 云+导语：4月22日，由腾讯云和 Kafka 社区主办、开源中国协办的腾讯云+社区技术沙龙 Kafka Meetup 深圳站在腾讯大厦举行，本次活动全程干货满满，不仅有 Kafka 的前世今生及展望，也有对 Kafka 技术架构的深入解析，同时还有基于 Kafka 的应用平台的相关开发与运维实践。活动异常火爆，现场近三百人参与交流，不少参会者表示活动质量很高，不虚此行。 现场听众 Apache Kafka 的过去、现在和未来 2010年，LinkedIn 着手开发 Kafka，到2011年 Kafka 进入 Apache 孵化器，成为世界顶级开源项目，并迅速被各种企业采用。据分析，目前已经有超过70%的世界500强公司在使用 Kafka。Kafka 主要作者、项目委员会主席及 Confluent 联合创始人饶军首先为大家带来了《Apache Kafka 的过去、现在和未来》的分享，介绍了 Kafka 这一路的各个关键节点及展望。他认为“Kafka 未来不仅仅是一个实时数据收集和传输系统，随着接下来的发展，它更偏向于成为一个实时数据流处理、交换和共享的平台。” 饶军：Apache Kafka 的过去、现在和未来 Kafka 集群自动化运营实践

近日，好雨科技与龙芯中科共同进行了好雨科技旗下云帮（Rainbond）PaaS平台与龙芯中科最新龙芯3B3000芯片的测试认证。 测试结果表明：在最新龙芯3B3000芯片上（具备向下兼容），云帮PaaS的通用兼容性、运行稳定性、功能可靠性等方面均达到生产要求，能够满足军工、政务等用户的关键性需要。 好雨科技作为云计算时代的PaaS服务商，立足于“数字化业务驱动企业价值增长”，打造“以应用为中心”的PaaS平台，管理企业数字化业务的“开发、架构、交付、运维”应用全生命周期。 龙芯中科定位于面向国家信息化建设的需求，面向国际信息技术前沿，以创新发展为主题，以产业发展为主线，以体系建设为目标，坚持自主创新，掌握计算机软硬件的核心技术，为信息产业及工业信息化的创新发展提供高性能、低成本、低功耗的处理器。 此次互认证为好雨科技及龙芯中科提供更大的合作空间，有助于双方共同拓展军工、政务等领域，推进云计算融合创新能力，提供安全可靠的云环境，构建稳定健康的云生态。 来源： oschina 链接： https://my.oschina.net/u/584116/blog/3076292

SAMIR BEHARA 本文将解释Service Mesh相关概念，为什么云原生应用需要它，以及这项技术被社区热烈拥抱、积极采用的原因。 毫不夸张地说，微服务已经席卷了整个软件行业。从Monolith过渡到微服务架构，可以让我们频繁、独立而可靠地部署应用。 然而，在微服务架构中，一切都不是绿色的，它必须处理在设计分布式系统时遇到的相同问题。 然而，微服务架构不是万能的，在设计分布式系统时会遇到很多有待解决的问题。说到这里，我们不妨首先回顾一下关于分布式计算的8大谬误—— 网络是可靠的（The Network is Reliable） 延迟为零（Latency is Zero） 带宽是无限的（Bandwidth is Infinite） 网络是安全的（The Network is Secure） 拓扑不会改变（Topology does not Change） 有一名管理员（There is one Administrator） 传输成本为零（Transport Cost is Zero） 网络是同质的（The Network is Homogenous） 在微服务体系结构中，对于网络的依赖带来了可靠性问题。随着服务数量的增加，我们必须处理它们之间的交互，监视整个系统的健康状况，处理容错、日志记录，处理多个故障点等等。每个微服务都需要有这些共同的功能，以便服务通信是平滑和可靠的

Lori Macvittie 微服务架构是把双刃剑，我们享受它带来的开发速度（development velocity），却也不得不面对服务间通讯带来的复杂性问题。 目前大多数扩展容器化微服务的架构多是基于proxy-based复杂均衡器实现的。在这些架构的问题在于，容器环境内部伸缩往往依赖于IP tables，并受制于传统网络层。 所有这些代理提供相同的核心功能：扩展容器环境中的分布式服务。这些服务是一种短暂的构建（ephemeral constructs），实际上并不存在——除了在定义它们的资源（配置）文件中。基于IP tables的扩展解决方案的问题是，这些服务是7层(HTTP)构造，通常充当单个API调用的“后端”，而非整个应用程序。 正如我们所知道的，从客户端显示为单个、整体构造的应用，实际上由许多不同的(和分布式的)微服务组成。有些服务是纯内部的，供其他服务使用，这意味着要在容器环境中进行大量的service-to-service通信。 在这些环境中，一切都是HTTP/HTTP2之上的api，因此我们需要L7(HTTP)路由。我们还需要一致的安全、身份验证和策略执行。所有这些都是基于IP tables的方法无法实现的。 针对种种微服务架构服务间通讯的问题和难点，目前出现的一些Service Mesh相关开源项目已经开始着手解决这些挑战，核心集中于以下8个方面： 构建 -

George Miranda 业务对于Service Mesh微服务架构的讨论热度居高不下，很多人认为Service Mesh将是云原生应用基础设施解决方案的MUST，它在构建健壮微服务架构应用时的能量令人印象深刻。不过在人气飙升的同时，人们对于落地Service Mesh的确切价值仍有困惑，因此有必要深入了解什么是Service Mesh以及它解决了哪些问题，以便我们确定是否真的需要Service Mesh。 Service Mesh Service Mesh是一个用于处理服务之间通信的基础结构层，其体系结构的具体细节在不同实现中略有差异。一般来说，每个Service Mesh都是作为一个系列(或“mesh”)实现的，这些相互连接的网络代理设计允许我们更优雅地管理服务流量（service traffic）。 该解决方案随着微服务架构的广泛接受而兴起，它引入了一种全新的通信流量（communication traffic）概念。但不幸的是，采用者往往没有做太多的考虑。这有时被归因为南北流量模式与东西流量模式的区别。简单来说，南北流量是server-to-client流量，而东西流量则是server-to-server流量。以上命名来源于“映射”网络流量的关系图，图中通常用垂直线表示server-client流量，水平线表示server-to-server流量。在Server-to

容器!容器! 回溯历史源头 相比于盛极一时的 AWS OpenStack 以Cloud Foundry为代表的PaaS项目，却成了当时云计算技术中的一股清流 Cloud Foundry项目已经基本度过了最艰难的概念普及和用户教育阶段，开启了以开源PaaS为核心构建平台层服务能力的变革 只是,后来一个叫 Docker 的开源项目横空出世 当时还名叫 dotCloud 的 Docker 公司，也是PaaS热潮中的一员 相比于Heroku、Pivotal、Red Hat等PaaS新宠， dotCloud 微不足道，主打产品跟主流的Cloud Foundry社区脱节，门可罗雀! dotCloud 公司突然决定：开源自己的容器项目 Docker ！！！ 显然，这个决定在当时根本没人在乎。 “容器”这个概念从来就不是什么新鲜的东西，也不是Docker公司发明的。 即使在当时最热门的PaaS项目Cloud Foundry中，容器也只是其最底层、最没人关注的那一部分。 PaaS项目被大家接纳的一个主要原因是它提供“应用托管”能力 那时主流用户的普遍用法，就是租一批AWS或者OpenStack的虚拟机，然后像以前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。 当然，部署过程难免碰到云端虚拟机和本地环境不一致问题，当时的云计算服务，比的就是谁能更好模拟本地服务器环境，带来更好“上云

架构中的其他平台是企业数据中心中需要纳入管理的平台，例如大数据平台、kafak平台等。 来源： https://blog.51cto.com/031028/2433342

K讲啦直播倒计时2天 长按识别下方二维码（或点击阅读原文），即刻报名 -END- 推荐阅读 直播报名丨 Pivotal权威解读：云原生和DevOps解决方案 动态丨 Nebulogy品牌定位重磅发布，释放“智能+”新动能 干货丨 BizDevOps推动企业数字化转型与高速增长 Nebulogy 品牌介绍 Nebulogy致力于通过云原生理念，帮助企业构建PaaS平台，提高开发资源利用率，满足应用快速上线和迭代需求，助力企业实现真正应用云化、业务互联网化。 网站： http://www.nebulogy.com 邮箱：service@nebulogy.com 来源： https://my.oschina.net/Nebulogy/blog/3098588