微服务和容器对企业带来什么样的影响?
【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》
IT经理、架构师和开发者都尝试妥协于微服务和容器对企业IT方式的改变。在某一个层面来说这是一件好事,但是事实上,一些更深层次的东西在驱动着技术和IT。
要理解微服务和容器,可以从抓住它的价值定义开始,然后将IT和数据中心的性能与这个变革的驱动者进行匹配。***,为了敏捷性来构建架构,而不是为了追随下一个大热点来构建架构。
IT策划者和经理们一定要了解到应用程序和工作者之间基本关系的变化——特别是事件驱动型、移动的工作者——他们是使用容器和微服务的驱动者。IT方向的转变会让昂贵、长期存在的基础架构向动态的市场进行靠齐。这意味着不仅仅是更多高效的云服务或者更低的操作复杂性,还能更好地对他们IT的需求进行响应。
现代的工作者
应用软件从记录业务活动进化到促进业务活动。应用程序创建了一条企业可以跟随的创建运营计划的最小阻力路径。企业架构师已经通过数十年的努力想把应用程序与业务的目标达成契合,但是他们通常会被现在用来经营业务所使用的可用的IT工具所阻碍。
智能手机设备的出现加速了这个现象。手机app的工作者需要得到对他们工作的支持,而不是遵循一些已经预定义好的工作流。手机工作者是事件驱动型的,这意味着应用程序也需要这样。微服务不是为了IT发展所寻求得商业计划,而是一种响应战略性需求的构造应用的方法。
比传统的虚拟化更少的日常开销
在应用程序的层面,微服务促使架构师和开发者不仅仅把产品特点和流程当成是服务,而是重新思考整个流程和应用组成的概念。伴随着面向服务的架构体系( SOA))和其他基于服务的方法论,流程将组件捆绑变成组合的应用程序。微服务的目标是让工作者的工作和组合的营养程序绑定到一起。每一步和特性都是按需求而定的。
可能微服务和敏捷IT带来的***的影响就是每一个组件都变得很关键。在一个应用模型中,每一个组件的组成都是显而易见的,所以你可以有根据地将关键和非关键的app分开。但是在微服务模型里,一个组件可能是关键app的一部分,也可能不是,这取决于工作环境。规则、安全和可用性必须在所有地方都达到要求,而不仅仅是需要的地方达到要求就可以。
微服务临时的特性是驱动着容器技术的关键。而虚拟化,不管是在数据中心还是在云端,不管是如何组合的都会有比较高的应用程序开销。如果服务是小型的、策略性的,那么虚拟化的费用是很难平衡的。如果微服务有广泛的接受程度,那么容器会更加普遍,微服务会成为事件驱动型IT模型的基础。
微服务一定要基于正确的组件架构上,这会让IT能动态地部署和规划组件。非状态化组件和更功能性的编程方法会主动阻止开发者创建状态化的组件。开发经理和架构师现在已经有一些功能性的工具,比如厂家微软和Oracle通过Lambda表达式创建的的功能性编程。但是他们还是需要围绕着微服务的开发环境来做一些功能性的领域,因为编程的必要模型还是存在的。
增强后端
采取容器技术并不意味着保证数据中心会进化成***去支持微服务和事件驱动型IT。当程序变得越来越敏捷也意味着对它们的开发会变得越来越没有效率。通过几步来阻止这一切的发生吧,与业务负责人和开发者进行协商,让应用在设计的时候就避免过多的、没有保证的部件化。失控地使用微服务会带来IT的低效率,且不会提高最终用户的敏捷性。除了这些,IT运营团队还必须修正数据中心运营的方式和数据中心本身。
微服务和事件驱动型组件在网络延迟最小的情况下是最有效率的,这包括通过整个数据中心的延迟,以及多个数据中心或者公有云服务之间的延迟。使用快速的局域网作为数据中心的核心,在服务器和网络适配器上提供优化过得网络路径,避免虚拟交换机的过载。连接多个数据中心来减少延迟和丢包,这会严重恶化微服务的性能。
不能变快的应该被阻止。按需要规范新的应用程序部署和DevOps工具,让微服务变得合适。托管微服务到接近需要连接的地方,同样也要离固定的资源比较近,例如数据库,来避免过多的传递延迟。在将微服务放到IT资源的时候,要寻找编排的工具来考量以上这些点。对IT运营人员进行培训,让他们在安装参数和策略的时候提供正确的连接信息。
微服务和容器,被业务敏捷性所驱动着,它可能会产生一个巨大的力量来强迫数据中心接受私有云,支持混合云部署。当在虚拟化环境下建立微服务和容器模型成为可能的时候,对敏捷应用的需求会影响特性和功能的迁移。对云友好的内部实践和客户创新的公有云采纳方案会让弹性组件缩放自如。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Google 可能在与小米、索尼等公司合作开发 Fuchsia OS
【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 有迹象表明,Google 可能在与三星、小米与索尼等公司合作开发 Fuchsia OS。 目前 Google 的新一代操作系统 Fuchsia OS 几乎都是在 Google 自家的设备(Pixelbook 与 Nest Hub)上进行开发测试的,但是上周9to5google发现Fuchsia 有处理与 Google 的一系列合作伙伴相关的问题,这可能意味着 Google 可能在与三星、小米与索尼等公司合作,针对 Fuchsia OS进行开发测试。 Fuchsia 是一个基于功能进行模块化的跨平台操作系统,很重要的一点是它是一个“非 Linux 系”的系统。它采用 Google 的全新微内核 Zircon,并使用 Dart 和 Flutter 打造全新的 UI。Fuchsia 致力于打造一个移动与 PC 大统一的生态,支持 64 位 Intel与 ARM 处理器,并且传闻其会专注于嵌入式领域,并应用于 IoT。 目前 Fuchsia 已经将开发中的 bug 跟踪迁移到了不对外公开的 Monorail 上,但是在页面...
- 下一篇
让代码审查扮演更好的角色
【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 代码审查(Code Review)是很多大公司里面都有的一个流程。它指的是一个人编码,另有几个人负责审查,并提出修改意见。代码审查在大多数情况下对公司整体的工程质量是有提高的,但是如果使用不当的话,很可能反倒会降低工程质量。代码审查究竟在一个组织里面是有正面效应或者是负面效应取决于很多因素,而我认为其中最重要的是代码审查在开发过程中扮演的角色。 首先,我们先看看在代码审查中所需要找出的问题类型。它们可以是: 语法及代码风格问题:一般有静态检查工具可以解决,但难免有疏漏。 效率问题:需要有一定经验的人来辨别低效的部分。 命名问题:这其实是一个很经常出现也很重要的问题。对于一个人来讲说得通的命名不见得对于团队而言说得通,所以很多时候较难的命名要由团队通过代码审查协同解决。 设计问题:小到接口的设计,大到服务间通信的协议,都属于设计问题,根据情况可以由小部分人或者整个团队解决。设计问题是代码审查中最常见的问题。 对于前三种问题,相对来讲都很好解决。其中相对棘手的莫过效率问题,但实际上基本上知道效率问题的人都知道优化方案。...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- CentOS8编译安装MySQL8.0.19
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装