1、什么是PaaS?

 

 

l 2014-2015年,大家都在安逸的使用IaaS服务
l 亚马逊AWS的部署能力方面比所有竞争对手加起来还大5倍之多,2014年盈利6.6亿美元,2015年Q1盈利2.65亿美元

l 阿里云在国内客户总数为140万,2015年Q3盈利6.49亿元

 

2、容器

 

l 容器是操作系统内核自带能力,早已存在。基于linux内核已实现的轻量级高性能资源隔离机制 (cgroups, namespace, lxc)

l 虚拟机是操作系统级别的资源隔离,容器本质上是进程级别的资源隔离,所以容器可以秒级启动, 比VM要轻量很多

l Docker并没有发明容器,它的核心思路在于实现应用和运行环境的整体打包,统一镜像格式 l Docker只是容器的一种,还有rkt, warden等,几乎每个大厂都会自己搞一套

3、容器的历史

4、容器真的美好吗?

5、离容器还有多远?

互联网行业的基础设施建设,任重道远,只能按部就班,快速递进,这个时代抛弃谁连声baybay都不会说的!

6、Google到底想干什么:borg–>k8s

7、用kubernetes后的感觉

8、企业用kubernetes还缺点什么:

  • 网络SDN

  • 集群规模调优

  • 容器图形化编排

目前k8s问题比较集中的一些:(已优化)

• 增加关闭容器oom功能
• 容器重启策略增强
• 日志格式优化,更便于解析 • 环境依赖检测功能增强
• 增加容器cpu带宽限制
• 增加容器IO带宽限制
• 增加内存节点限制
• 增加内核内存限制

• 增加内存预留机制
• 增加swap内存限制
• Dockerexec增强,增加指定用户和特权用 户执行exec
• Dockerbuild资源限制增强
• 增加ARM64支持
• 安全加固,增加seccomp支持
• 增加在容器内获取cgroup信息功能

  • 未来的云容器栈(或)

  • 需求是一切的起点和终点

用户体验越来越重要

业务更替越来越频繁

数据处理越来越成为企 业的核心竞争力

服务端集群越来越复杂

分布式,增量式开发

持续集成,自动化测试

松耦合,微服务架构

按需伸缩,自动化运维 • 容器镜像发布

 

这一切都依赖于 容器集群

各种新技术将受益于容器集群能力

用户会以想象不到的方式使用技术

这份新的技术出口管理新提案内容相对简洁,清晰罗列了可能会影响强大国家安全或者经济体的14类新兴和基础技术。

1、生物技术
例如:
(1)纳米生物学;
(2)合成生物学;
(3)基因组和基因工程;
(4)神经科学。

2、人工智能(AI)和机器学习技术
例如:
(1)神经网络和深度学习(例如:脑建模、时间序列预测、分类);
(2)进化和遗传计算(例如:遗传算法、遗传算法);
(3)强化学习;
(4)计算机视觉(例如:物体识别、图像理解);
(5)专家系统(例如:决策支持系统,教学系统);
(6)语音和音频处理(例如:语音识别和制作);
(7)自然语言处理(例如:机器翻译);
(8)规划(例如:调度、博弈);
(9)音频和视频处理技术(例如:语音克隆、deepfakes);
(10)AI云技术;
(11)AI芯片组。

3、定位、导航和定时(PNT)技术
4、微处理器技术
例如:
(1)片上系统(SoC);
(2)片上堆栈存储器(Stacked Memory on Chip)。

5、先进计算技术
例如:内存中心逻辑(Memory-centric logic)。

6、数据分析技术
例如:
(1)可视化;
(2)自动分析算法;
(3)上下文感知计算。

7、量子信息和传感技术
例如:
(1)量子计算;
(2)量子加密;
(3)量子传感。

8、物流技术
例如:
(1)移动电力;
(2)建模与仿真;
(3)全资产可见性;
(4)物流配送系统(DBLS)。

9、增材制造
例如:3D打印。

10、机器人
例如:
(1)微型无人机和微型机器人系统;
(2)集群技术;
(3)自动装配机器人;
(4)分子机器人;
(5)机器人编译器;
(6)智能灰尘。

11、脑-机接口
例如:
(1)神经控制接口;
(2)意识-机器接口;
(3)直接神经接口;
(4)脑-机接口。

12、高超音速空气动力学
例如:
(1)飞行控制算法;
(2)推进技术;
(3)热防护系统;
(4)专用材料(用于结构、传感器等)。

13、先进材料
例如:
(1)自适应伪装;
(2)功能性纺织品(例如:先进的纤维和织物技术);
(3)生物材料。

14、先进的监控技术
例如:面纹和声纹技术。

根据现在云计算和DevOps的现态,我觉得一个成熟的自动化运维平台应该包括以下的特性:

一、支持混合云的CMDB

现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一个自动化CMDB的基础。新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。通过API对资源的操作都应该被作为操作日志记录下来,以备作为后续操作审计的基础数据。CMDB这个东西听上去是老生常谈,但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦,就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来,就意味着一旦要增加一台服务器,可能要在各个运维工具里面都要同步一下。尤其是容器化以后更是必要,明确CMDB规范则是CMDB的第一步。

二、比较完备的监控和应用性能分析(APM)

能支持对平台的可用性、服务器的性能、各种服务(web服务、应用服务、数据库服务)的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。现在市面上一般都会将资源性能监控和应用性能监控(APM)混合着讲,这里面的产品确实也有很多都是重叠的,两方面都会涉及到。开源的性能监控系统主流有的Zabbix、Nagios,国产的开源监控平台有小米OpenFalcon,但这些基本都只是做基本的资源监控(服务器,磁盘、网络等)和简单的服务软件的性能监控(中间件,数据库等)。而市面上的APM系统更主打的功能是应用性能分析,比如能精确定位到某个应用的URL的访问速度快慢,方法栈的开销变化,某些SQL执行速度的快慢,这些对于开发人员和运维人员快速定位问题还是很有帮助的。APM这方面的商业工具,国外比较主流的有New Reclic、Dynatrace,国内的也就是透视宝、Oneapm、听云等,他们也提供了API进行集成。APM这方面的开源工具有pinpoint(一个韩国团队开源的),zipkin(twitter开源),cat(大众点评开源)。需要这种强调一点的是对于监控工具的监控是一个成熟team的重要标志之一。

三、有一个凑活UI的批量运维工具

在业务发展比较快的情况下,从几台服务器,到几十台服务器,再到几百台服务器,批量运维的需求很自然就产生了,老板也希望越少的人干越多的活。现在也有不少开源的批量运维工具,也都比较成熟了,比如puppet、chef、ansible(1.8以后变化成rpc了)、saltstack。puppet和chef都是ruby做的,实话实说,ruby的熟手中国市面上很少,比python不是难招一点。我个人比较推荐使用ansible或者saltstack,这两个系统都是python写的,代码质量和社区活跃度都挺不错的。ansible有官方的web ui——Tower,ansible在两年前还是很火的,主要是基于ssh进行socket的shell操作,现在在变化目前地想让其更快一点,实际还不如saltstack好用,所以我们也在重新做一套自己用起来更顺手的WEB UI。

四、日志集中分析工具

线上系统最常规的问题定位方式,就是日志分析了。随着服务器的增多,日志的分析定位也成为一个难点和痛点(想象一下,系统出故障之后,要去几十甚至数百个节点去上去查日志,是有多折腾)。日志分析这个领域现在是一个热点,现在的开源方案也比较多了,比如著名的ELKStack,还有Flume+Kafka+Storm的体系。上面这两个方案相对重一些,部署比较复杂,网上介绍的文章也不少,看官仔细辩解,坑不少。比较轻量级的开源日志集中采集方案有python做的Sentry,他是通过改造各种语言的日志采集框架来实现日志的集中采集,各种主流的开发语言的日志框架都支持得很完整了,比如java的log4j和logpack。Sentry:Sentry – Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js

五、持续集成和发布【CICD】工具

08ece6567a893083c59abcc9bfe0c61c继续阅读

首先需要清晰概念,什么是微服务,为什么需要微服务?

微服务是一种思想,落到实际简单说就是将原来的工程应用拆分成不同的小应用,每个小应用都是一个相对独立的项目,可以独立的迭代启停并接受CURD等接口(REST或RMP或SSH)用于req和res。

微服务的好处,可以很好的解耦数据、产品、开发、基础设施等,使维护迭代大型应用变成可能,变成全异步和全并行,微服务实际也是一种解决方案,必然他也不是银弹;当然,凡事都有两面性,微服务也有很多不利或者坑,如果不有效解决就会造成很大的麻烦:盲人摸大象。

首先,目前很多公司现在的交付场景:

然后,再看看微服务下的交付场景:

两下一对比我想,好处坏处、利弊得失和动静的维度立刻就显现出来了:

1、工作流,一个总体串行局部串行的一个是总体分步分项局部串行与交叉并行的;

2、我个人微服务有9个比较重要的特征:服务组件化、按照业务组织team、开发与产品融合度提升(模块开发逻辑要准寻产品的演化逻辑)、智能端点和哑管道(服务调用的端点动态获取,加权与熔断)、去中心化(语言与框架的选择多样性)、数据管理去中心化、基础设施自动化、容错设计(网络是不可信的组件是不可信的,降级、灾备、伸缩势必智能且变成可行)、演进设计变成进化式设计

3、微服务的缺点:

3.1 大型项目系统拆分,技术成本高企,对技术人员的要求也会提高很多

3.2 更清晰的服务边界也使得标准化变得困难,微服务非常依赖上层框架来进行规约,否则迭代的时间成本、断服成本和协调成本变得很高

3.3 大个单体应用内部通讯成本远低于微服务组件通信成本

3.4 DB的设计与业务规划变成难点和痛点

3.5 多组件有效健康管理是头等要务,全链路监控、报警、调度、审计就变的非常有挑战性

。。。。待续

好久没写博客了,一直在“炼剑庐”闭关铸剑!抱歉….   🙁

        今天利用“出来放风”的10分钟写写一些简单的感悟。   🙂
        自打AI和大数据,以及大数据和云计算,以及新网络和IOT,近年快速出现以后,对于ai的挖掘和深化正在改造着互联网以及硬件行业商业的航向。下面简单记录一下我的想法,这是我在实践中的切身感悟,绝非别人之言的简单终结和概括。
        接下来的互联网科技公司一定是“软硬双开”的才能长成参天大树,其他的将会被蚕食和分解,无论BATJ等等公司,技术team的变化也正在向着“大前端”和“大后端”分离的方式发生,具体的表现就是一个站点或者产品仅仅使用一两个全栈开发工程师就可以完成以前数十个人才能完成的开发工作,请看清楚就一两个人就可以,像ios、android.、mac、windows 和windowsphone的开发也将拧和到基于浏览器的APP一键生成;后端将会向数据方向和智能化方向聚拢,并彻底的与运维和硬件分离,说的严重一些,甚至是“大前端”、“大后端”和“计算层”三者之间并不需要互相认识,仅仅通过API和OA就可以处理解决一切问题并完成产品交付、发布、迭代。这样的互联网时代已经来了,无人化正在融入我们的生活!!!
        简单的人数计算就是,一个细分市场的大中等规模的产品线的开发,只需要以下不超过十个人就完成了,网站开发(全部网站实现3-6人)、BI(2-4人)、AI(3-5人)、cloud(1-3人)加到一起也就全部完成了。再加上硬件驱动和嵌入式就更是如虎添翼!
        对,你想到了产品,说明你是行内人士!其实接下来产品是模块化、组合化的,就是说用户可以根据自己的需求和习惯自动生产组装一个app,并且这个app会更具用户的需求变化和成长瞬间重新组装。
        这就是未来的互联网产品和全架构世界!!!这是一个无限计算的世界。是一个“新工业时代”。
        没听懂?!没看懂?!
        不会吧,那就联系我吧(william@chinaase.com),我给你细细的“庖丁解牛”,别以为码农就没有仰望星空+俯身拉扯的人,我一定会让你吓一跳!