PaaS

pass平台开发运维一 1.在 server 节点使用 netstat 命令查询仓库监听端口号，查询完毕后通过 lsof命令（如命令不存在则手工安装）查询使用此端口号的进程。将以上所有操作命 令和输出结果以文本形式提交到答题框。 [root@server ~]# netstat -atunpl Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 796/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 901/master tcp 0 52 10.0.0.8:22 172.16.10.106:49222 ESTABLISHED 1620/sshd: root@pts tcp6 0 0 :::2375 :::* LISTEN 960/dockerd-current tcp6 0 0 :::5000 :::* LISTEN 1217/docker-proxy-c tcp6 0 0 :::8080 :::* LISTEN 1176/docker-proxy-c tcp6 0 0 ::

时间过得真快。openstack与docker已经发展有些年头了，刚刚开始时总认为IAAS层面发展PAAS有一定的限制，可能自己也一时钻了牛角尖，认为IAAS层上的 paas只是在镜像中添加他们的应用，直接开出虚拟机就可以。 这也是沿袭着原始IAAS层的想法从一个小tag地方做一个改进。 可是后来我接触了PAAS的实 现方式，突然觉得kubernetes，openshift，真是不错，它能更好的编排容器。但是此时的IAAS和PAAS还是单独分开来做的。再后来我接触了kolla项目， openstack社区开源实施解决方案，突然感知到这个想法太好了，它突破了原有的方式。创造了新的方式。让IAAS和PAAS可以很好的结合在一起。 实践后， 我突然觉得kolla-kubernetes绝对是openstack最佳的部署方式，它不但让IAAS更加容易部署，还让PAAS与IAAS有机的结合。这定然是中小型私有云最佳解决方案， 我坚信自己的想法。先记下来，以后时间验证。 活在当下： 云计算 云无非分为IAAS，PAAS，SAAS。 基础设施层面IAAS和PAAS已经ok，saas么？ 也就是软件即服务，说白了，开发应用放到上面呗。 AI+大数据 对大数据不是很了解，等以后深入了解了hadoop，spark。再来说 对于AI这块，感觉谷歌开源的tensorflow可能成为以后的标准。 区块链

I am planning to migrate few products on Cloud which will be used as a platform for the developer community. In short I am trying to host PaaS vendor for my products which can be consumed by developers for build and development process. The plan is as below: I am trying to use Amazon IaaS ( S3, EC2) as the hardware. I will require a cloud management software which can be installed somewhere on one of my local systems and can manage the Amazon cloud. I will deploy all my products on the Amazon Cloud with the help of the Cloud Management Software. I will develop and provide APIs to my end users

强如银行巨头，也有难翻的火焰山？ 伴随互联网+ 趋势的推进，越来越多金融公司业务渠道从线下转移到线上，业务场景发生质的转变与提升。 支付场景多样化和人们消费水平升级，随之而来的是各大平台频繁打造的营销日、促销节，典型如双十一狂欢节，同一时段产生高并发交易需求，极易引发服务器崩溃的尴尬局面。银行系统处理用户交易信息时，还会因为负载过大出现返回超时。 银行传统的IT架构无法满足互联网上的秒杀、节日抢红包等超大流量业务模式。于是，通过容器技术进行弹性伸缩的方式，在实践中逐步被大量采用。此外，资源池化技术、面向服务高并发框架、虚拟化、大数据、微服务等技术被接入银行系统架构中。 以微服务快速响应业务变化 一个真实案例：某金融企业成立6年，业务涵盖8大领域，目前成为国内几家较大的消费贷服务公司之一。截止18年初，该公司服务网覆盖全国近30省份、200座城市，签约商户55000余家，员工1万人以上，150多套业务系统，涉及多种不同领域的服务。 客户激增使该公司业务面临高并发访问的巨大压力，传统IT 架构缺乏对于应用快速弹性伸缩、自动故障恢复、服务编排、灵活迁移和负载均衡等能力，无法及时 响应业务的快速发展 。 随着业务服务范围的扩大，传统IT 开发、上线模式在各环节存在流程脱节；应用部署标准化程度低，部署和维护基于经验， 难以自动化、平台化，应用部署耗费大量人力 ，工作量剧增

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

作者 | 张振（守辰）阿里云云原生应用平台高级技术专家 导读 ：2019 年阿里巴巴核心系统 100% 以云原生方式上云，完美地支撑了 双11 大促。这次上云的姿势很不一般，不仅是拥抱了 Kubernetes，而且还以拥抱 Kubernetes 为契机进行了一系列对运维体系的深度改造。 Kubernetes 作为云原生的最佳实践，已经成为了事实上的容器编排引擎标准，Kubernetes 在阿里巴巴集团落地主要经历了四个阶段： 研发和探索：2017 年下半年阿里巴巴集团开始尝试使用 Kubernetes api 来改造内部自研平台，并开始了对应用交付链路的改造，以适配 Kubernetes； 初步灰度： 2018 年下半年阿里巴巴集团和蚂蚁金服共同投入 Kubernetes 技术生态的研发，力求通过 Kubernetes 替换内部自研平台，实现了小规模的验证，支撑了当年部分 双11 的流量； 云化灰度： 2019 年初阿里巴巴经济体开始进行全面上云改造，阿里巴巴集团通过重新设计 Kubernetes 落地方案，适配云化环境，改造落后运维习惯，在 618 前完成了云化机房的小规模验证； 规模化落地：2019 年 618 之后，阿里巴巴集团内部开始全面推动 Kubernetes 落地，在大促之前完成了全部核心应用运行在 Kubernetes 的目标，并完美支撑了 双11 大考。

小米中台建设实践 01 小米的三大中台建设：业务+数据+技术 业务中台--从业务说起 在中台建设中，需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况，判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等，再结合其业务发展历程及业务现状，整理了中台架构的核心方法论，一是企业如何共享服务，二是如何为业务提供便利。 通过中台架构方法论和规划方法论，小米信息部提出了小米业务中台建设三年战略，包含了持续优化、构建中以及待新建的系统，纵向分为企业战略、业务执行、业务支撑、数据治理四部分。在2018年成立时，系统还是比较分散的；在2019年，主要围绕中台的架构调整、技术体系下沉，强化运营配置中心三方面，实现绝大多数的共享服务，让小米复杂的业态共享一套体系，更好的支持业务；在2020年，期望整体完善，不断的持续优化。 数据中台--数字化转型的核心 今天大家都在谈数字化转型，数字化转型是转什么？从企业内部来讲，是想如何把一切都数字化，大企业讲数字化转型是很难的一件事情，但现在有些小企业已经做得非常好。系统很简单，但是可以把企业的百十家或者几百家店铺的每一个动作、每一次上下架，甚至是每次的价格变更，每个操作人员的动作，都放到系统里面做记录。 数字化转型，业务是基础，核心是数据。在数据分析及使用过程中，小米主要面临3大问题