PaaS

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 用过新浪云的pass中的php环境，觉得还是很方便的，发布变得简单。只需要用ftp客户端把代码提交上去。就可以发布程序了，而不需要配置php运行环境。 今天在开源中国首页上看到了关于tsuru的推荐，是一个开源的pass软件。可以构建自己的pass平台，觉得还是挺棒的。又看到红薯翻译的文章 http://www.oschina.net/translate/build-your-own-paas-with-tsuru-and-docker（使用 Tsuru 和 Docker 构建自己的 PaaS 系统） http://www.oschina.net/translate/building-your-tsuru-service（构建你自己的 Tsuru 服务） 可以在linux上部署起来。还是等我在笔记本上把unbuntu安装起来吧。 来源： oschina 链接： https://my.oschina.net/u/1585200/blog/741205

据IDC最新发布的《软件定义计算软件市场半年跟踪报告》显示，2019年上半年中国软件定义计算软件市场的市场规模达到了3.4亿美元，同比增长36.3%。IDC预测，该市场在数据中心现代化、企业基础架构云化以及云原生应用普及化的趋势下，在未来五年其复合增长率仍将达到24.8%，到2023年市场规模将达到20.3亿美元。 容器市场将呈现爆发式增长 现阶段，在软件定义计算软件的三个子市场中，虚拟化软件仍然占据了最大份额。IDC预测，在未来五年，随着中国企业服务器虚拟化***率逐渐提高并且趋向于稳定，虚拟化软件市场的增长将逐渐放缓；而云系统软件和容器基础架构软件则维持高增长，逐渐成为助推软件定义计算软件增长的主要动力。特别是近两年被大家关注的容器市场，更是呈现爆发式增长。 伴随着云原生和混合云的热潮，容器是这两年最被市场所关注，发展速度最快的IT领域之一。容器发展之初，使用者大都集中在互联网企业，大多数传统企业还处于探索和评估阶段，或者借助开源版本尝试小范围部署容器。这两年随着技术方向更加的清晰化，容器相关开源社区积极的拓展生态和技术，企业数字化转型对于敏捷架构和创新的需求，以及在企业中出现了越来越多的最佳实践，容器的商业化市场初见雏形。 容器市场呈多元化，创新型厂商表现活跃 IDC预测容器基础架构软件市场2019的整体规模是7340万美元，其所带来的的容器相关市场（搭建容器

近期，BoCloud博云收到了一封感谢信： 由BoCloud博云（全称：苏州博纳讯动软件有限公司）承建的某大型股份制银行信用卡中心（以下简称：卡中心）容器管理平台建设项目，在面对工期紧、任务重、要求高等诸多困难和压力下，我司高度重视与配合，在项目组全体成员的共同努力下，扎扎实实、勤勤恳恳、严谨负责、保质保量地完成了阶段性建设目标，为该卡中心应用的容器化工作提供了有力的技术支持与保障。 数字化转型发展到今天，其核心是促进业务变革与创新。伴随互联网+对银行业的深度渗入，使得To C场景与互联网的结合成为不可逆转的大趋势，银行业务的互联网化导致银行业务形态发生变化。传统IT架构已无法支撑互联网化业务的创新与变革，这意味着数字化转型时代，企业业务的敏捷与弹性，对企业底层IT架构支撑提出了更高的要求。 BoCloud博云根据该行信用卡中心应对互联网化业务快速发展和建设敏捷IT架构的需求，为卡中心建设了现代化容器PaaS云平台。该平台是基于DevOps和微服务理念，运用容器等技术，所搭建高可用、高弹性、响应快速开发迭代的容器PaaS云平台。建设内容主要分为： 1、建设高可用容器云PaaS平台 基于Docker和Kubernetes建设高可用容器云PaaS平台，通过平台提供分布式微服务框架与服务治理服务、容器生命周期管理、应用生命周期管理、智能运维、应用商店与分布式应用组件服务

很早之前，就有关于“每台机器（machine)应该有多少个服务”的讨论。在我们继续之 前，应该找一个比“机器”更好的术语。在前虚拟化时代，单个运行操作系统的主机与底 层物理基础设施之间的映射形式有很多种。因此，我倾向于使用“主机”（host)这个词来 做通用的隔离单元，也就是能够运行服务的一个操作系统。如果你直接在物理机上部署， 那么一台物理机映射到一台主机（在当前上下文中，这个词可能不完全正确，但确实也找 不到更好的了）。如果你使用了虚拟化，单个物理机会映射到多个独立的主机，并且每个 都可以包含一个或者多个服务。 所以在考虑不同的部署模型时，我会使用主机这个词。那么每台主机应该有多少个服 务呢？ 我有自己倾向的模型，但要考虑多个因素，来决定哪个模型最适合你。需要注意的一点 是：某些决定会限制可用的部署方式。 6.9.1单主机多服务 如图6-6所示，在每个主机上部署多个服务是很有吸引力的。首先，从主机管理的角度来 看它更简单。在一个团队管理基础设施，另一个团队管理软件的模式下，管理基础设施团 队的工作量通常与所要管理的主机量成正比。如果单个主机包含更多的服务，那么主机管 理的工作量不会随着服务数量的增加而增加。其次是关于成本。即使你有一个能够提供一 些配置和更改虚拟主机大小等服务的虚拟化平台，虚拟化的基础设施本身也会占用一部分 资源，从而减少服务可用的资源。在我看来

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Rainbond在v3.7.0版本中释出了大量平台稳定性更新，并在应用管理功能、安全性和系统安装三方面进行了部分优化。 作为IT基础系统平台，Rainbond从 低耦合的架构设计 、 高可用的部署方式 、 自恢复与容错的设计 三方面评估和保障分布式系统可用性，以最终达到无人值守的效果。 在低耦合架构设计方面，Rainbond将分布式系统抽象为管理、计算、存储等三类节点，不同节点属性由不同服务组件构成，以解除服务间耦合关系，同时对于不同节点，可用性的最低要求也不尽相同 —— 管理节点 ：面向用户，提供应用构建、控制、调度、交付以及数据存储等系列管理功能，在异常情况下没有管理节点，已有应用依然能正常运行 计算节点 ：负责实际运行应用并为应用运行提供环境保障，在异常情况下可以容忍降级，将应用调度到其他计算节点运行 存储节点 ：用于存储应用持久化数据并提供数据访问服务，存储节点异常，无状态应用依然可以正常运行。 为了更好地保证高可用的部署，Rainbond本身所有模块和组件均支持高可用 —— 管理节点 ：支持等幂部署多个节点以保证高可用 计算节点 ：等幂部署多个计算节点以组建冗余资源池，从而容忍单节点资源限制或故障 存储节点 ：采用冗余部署的方式形成存储资源池，对计算节点提供稳定服务，任何存储节点故障，业务不会中断

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本次 v3.7.0-rc1 版本，在上月发布3.6.1版本基础上，重点围绕系统生产稳定性展开，包括双重健康检查守护（Systemd进程级加Rainbond-Node业务级）、Prometheus监控指标暴露支持、管理节点上线下线支持等多项新增特性和优化。 除此之外，本次更新还对应用管理功能、安全性和系统安装三方面进行了部分优化，更新详情如下： 稳定性增强 所有平台服务使用Systemd进程级守护加Rainbond-Node业务级健康检查守护 所有平台服务支持健康检查和Prometheus的监控指标暴露 管理节点支持上线和下线以隔离由于节点故障导致的平台不可用 计算节点健康检查异常时支持自动隔离和恢复 支持配置自定义报警规则用于对节点物理监控、服务监控的报警 租户使用资源（内存、磁盘）的统计由单个节点完成（Rainbond-Worker Master节点故障时自动切换） 支持通过命令行工具便捷查询数据中心健康状态、所有节点健康状态 应用管理功能 支持 .NetCore(2.1)语言一键构建应用，运行于Linux系统 支持对接SVN代码仓库持续构建应用 增加自动构建的入口，支持通过自定义API、Gitee-Webhook、Gogs-Webhook触发自动构建,更好的于第三方CI系统集成。 支持应用

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> apiserver的list-watch代码解读 list-watch，作为k8s系统中统一的异步消息传递方式，对系统的性能、数据一致性起到关键性的作用。今天我想从代码这边探究一下list-watch的实现方式。并看是否能在后面的工作中优化这个过程。 0. list-watch的需求 上图是一个典型的Pod创建过程，在这个过程中，每次当kubectl创建了ReplicaSet对象后，controller-manager都是通过list-watch这种方式得到了最新的ReplicaSet对象，并执行自己的逻辑来创建Pod对象。其他的几个组件，Scheduler/Kubelet也是一样，通过list-watch得知变化并进行处理。这是组件的处理端代码： c.NodeLister.Store, c.nodePopulator = framework.NewInformer( c.createNodeLW(), ...(1) &api.Node{}, ...(2) 0, ...(3) framework.ResourceEventHandlerFuncs{ ...(4) AddFunc: c.addNodeToCache, ...(5) UpdateFunc: c.updateNodeInCache,