其实通过互联网的屡次变革提及,早期的C/S架构,到后来的B/S架构,一直到如今最广泛的M/S架构,他们的背后都是技术不断的优化改进,以适应促进IT技术的发展数据库
总体而言在过去10年时间,互联网技术能够说是以手工制造的方式为准,相似于传统销售,设计,制做,而后打包销售。每一个环节都须要大量的人员来操做,也须要不断服务器
有人接班学习来延续对应的环节。而将来10年将会是以流水线的方式为主 ,其主要缘由是互联网云计算技术的高速发展及可持续快速交付的业务需求。其对应的DevOps网络
方式将完美契合。开发运维一体化确切的说是一种方式,而这种方式须要全新的技术来支撑才行执行下去,咱们将之称为下一代核心技术。架构
2. 传统技术与下一代核心技术区别运维
传统的技术主要问题是高耦合,其耦合存在于服务器,硬件存储,内外网之间(网络通信),应用程序之间,代码之间,业务模块之间,虽然通过近几年的发展,在不断的微服务
去耦合化大趋势下,已经尽量的将这几大块之间进行低耦合处理,可是因为传统技术的限制,没法从根本上解决这些问题。好比最经常使用的程序链接数据库。传统的方式多工具
将数据库链接字符串写到程序的配置文件里,致使其链接数据库IP不能变,多节点部署程序须要一一手动修改数据库链接字符串。很是麻烦,随着技术的发展优化,有经验的学习
研发人员会将数据库链接放到JNDI里面(如Tomcat),由中间件管理,这样将程序和数据库之间进行解耦。这也是传统技术,架构经常使用的作法。可是对于多节点的部署变动,优化
须要改变多个节点Tomcat的JNDI配置,仍是存在易用性,可维护性,可靠性方面的问题。固然也有高级别的中间件来集中解决这些问题,如WebSphere的集群管理,这都属于云计算
为了解决问题而解决问题,受限于传统技术,没法从根因上解决各个组件,软硬件之间的耦合问题。并且须要商业付费,很是的贵。
下一代核心技术,受益于云计算,微服务,容器服务的高速发展,采起DevOps的模式进行整合,实现硬件服务器,存储,网络,软件程序,代码之间的全低耦合甚至0耦合
将大大提升交付能力,下降运维成本,实现互联网产品的快速迭代。
3. 容器服务的Rancher选型
我以前的文章已经对微服务作了基本分析,本章节及后续章节会陆续对云计算的分析应用和容器服务的分析应用作逐一的讲解。 微服务主要是对软件代码层面进行解耦,
云计算主要从硬件支撑层进行解耦,而容器服务主要从应用层面进行解耦。容器服务的飞速发展,主要是Docker的巨大功劳,将传统的虚拟化技术带到一个全新的层面。
Docker的优点在此不作多讲,主要是其原生的管理基于命令行,对于简单应用较为方便。可是在DevOps模式下就须要有一整套的规范接口来统一管理整个流水线。对于
Docker容器的管理系统目前比较流行的有几个: K8S,Rancher,Shipyard等,其余还有一些不是颇有名的在此很少作列举了,你们能够自行研究学习。
内容 | 原生 | K8s | Rancher | Shipyard |
管理端及易用性 | Docker EE (易用性★★★) | K8s管理(易用性★★) | Rancher(易用性★★★★☆) | (易用性★★★★) |
引擎/编排工具 | Swarm | Kubernetes | Cattle、Swarm、Kubernetes、Mesos,Windows |
无 |
多主(集群) | 支持 | 支持 | 支持 | 不支持 |
资源看板 | ★★★ | ★★ | ☆ | ★★★★ |
DevOps集成 | 不支持 | 插件支持 | 插件支持、原生支持 | 不支持 |
插件数量 | ★ | ★★★ | ★★★★ | 不支持 |
通过对比试用选型,在容器管理考虑到易用性包括跨主机通信的管理,DevOps的支持力度等方面,Rancher以各方面优先胜出。Rancher目前在开源社区很是火爆,支持众多
的编排引擎,当前最新版本为 1.6.12 ,你们能够下载试用。