微服务架构的优势与不足(三)
2019独角兽企业重金招聘Python工程师标准>>>
微服务架构的好处
微服务架构模式有很多好处。首先,通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的分支 或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由 此,单个服务很容易开发、理解和维护。
第二,这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术,提供API服务。当然,许多公司试图避免混乱,只提供某 些技术选择。然后,这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术,他们可以选择现在的技术。甚至于,因为服务都是相对简单,即使用现在 技术重写以前代码也不是很困难的事情。
第三,微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试,快速的部署变化。微服务架构模式使得持续化部署成为可能。
最后,微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的硬件。 比如,你可以在EC2 Compute Optimized instances上部署CPU敏感的服务,而在EC2 memory-optimized instances上部署内存数据库。
微服务架构的不足
Fred Brooks在30Year前写道,“there are no silver bullets”,像任何其它科技一样,微服务架构也有不足。其中一个跟他的名字类似,『微服务』强调了服务大小,实际上,有一些开发者鼓吹建立稍微大一 些的,10-100 LOC服务组。尽管小服务更乐于被采用,但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用,实现敏捷开发和部署。
另外一个主要的不足是,微服务应用是分布式系统,由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚 于,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事,但相对于单体式应用中通过语言层级的方法或者进程调用,微 服务下这种技术显得更复杂一些。
另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易,因为只 有一个数据库。在微服务架构应用中,需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择,不仅仅是因为CAP理论,还因为今天高扩 展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法,从而对开发者提出了更高的要求和挑战。
测试一个基于微服务架构的应用也是很复杂的任务。比如,采用流行的Spring Boot架构,对一个单体式web应用,测试它的REST API,是很容易的事情。反过来,同样的服务测试需要启动和它有关的所有服务(至少需要这些服务的stubs)。再重申一次,不能低估了采用微服务架构带 来的复杂性。
另外一个挑战在于,微服务架构模式应用的改变将会波及多个服务。比如,假设你在完成一个案例,需要修改服务A、B、C,而A依赖B,B依赖C。 在单体式应用中,你只需要改变相关模块,整合变化,部署就好了。对比之下,微服务架构模式就需要考虑相关改变对不同服务的影响。比如,你需要更新服务C, 然后是B,最后才是A,幸运的是,许多改变一般只影响一个服务,而需要协调多服务的改变很少。
部署一个微服务应用也很复杂,一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相对比,一个微服务应用一般由大批服务构成。例如,根据Adrian Cockcroft,NetFlix 有大约600个服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分,除此之外,你还需要完成一个服务发现机制(后续文章中发 表),以用来发现与它通讯服务的地址(包括服务器地址和端口)。传统的解决问题办法不能用于解决这么复杂的问题。接续而来,成功部署一个微服务应用需要开 发者有足够的控制部署方法,并高度自动化。
一种自动化方法是使用PaaS服务,例如Cloud Foundry。 PaaS给开发者提供一个部署和管理微服务的简单方法,它把所有这些问题都打包内置解决了。同时,配置PaaS的系统和网络专家可以采用最佳实践和策略来 简化这些问题。另外一个自动部署微服务应用的方法是开发对于你来说最基础的PaaS系统。一个典型的开始点是使用一个集群化方案,比如配合Docker使 用Mesos或者Kubernetes。后面的系列我们会看看如何基于软件部署方法例如NGINX,可以方便的在微服务层面提供缓存、权限控制、API统 计和监控。
总结
构建复杂的应用真的是非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用,那真的会很糟糕。微服务架构模式可以用来构建复杂应用,当然,这种架构模型也有自己的缺点和挑战。
在后续的博客中,我会深入探索微服务架构模式,并讨论诸如服务发现、服务部署选择和如何分解一个分布式应用为多个服务的策略。
愿意了解框架技术或者源码的朋友直接求求:1903832579
转载于:https://my.oschina.net/u/3873725/blog/1924240
微服务架构的优势与不足(三)相关推荐
- JHipster生成微服务架构的应用栈(三)- 业务微服务示例
本系列文章演示如何用JHipster生成一个微服务架构风格的应用栈. 环境需求:安装好JHipster开发环境的CentOS 7.4(参考这里) 应用栈名称:appstack 认证微服务: uaa 业 ...
- 微服务架构下的核心话题 (三):微服务架构的技术选型
前期回顾: 微服务架构下的核心话题 (一):微服务架构下各类项目的顺势崛起 微服务架构下的核心话题 (二):微服务架构的设计原则和核心话题 一.前言 为了实现基于微服务开发的产品,或者说为了将单体应用 ...
- 微服务架构的优势与不足
2019独角兽企业重金招聘Python工程师标准>>> 英文原文:Introduction to Microservices 这篇文章作者是Chris Richardson,他是早期 ...
- 微服务架构的优势与不足(二)
微处理架构--处理复杂事物 许多公司,比如Amazon.eBay和NetFlix,通过采用微处理结构模式解决了上述问题.其思路不是开发一个巨大的单体式的应用,而是将应用分解为小的.互相连接的微服务. ...
- SpringCloud微服务之微服务架构的优势
微服务架构有以下优势: 当人们将业务领域分解为可独立部署的环境时,能够将相关的变更后期解耦.只要变更限于单一有限的环境,并且服务继续履行其现有合约,那么这些变更可以独立于其他业务来进行和部署.其结果是 ...
- spring cloud+dotnet core搭建微服务架构:Api网关(三)
前言 国庆假期,一直没有时间更新. 根据群里面的同学的提问,强烈推荐大家先熟悉下spring cloud.文章下面有纯洁大神的spring cloud系列. 上一章最后说了,因为服务是不对外暴露的,所 ...
- 「微服务架构」基于NGINX的三种微服务参考架构
作者注:本博文是系列文章的第一篇: Introducing the NGINX Microservices Reference Architecture (this post) MRA, Part 2 ...
- 微服务实战(一):微服务架构的优势与不足
https://my.oschina.net/CraneHe/blog/703181
- 【项目实战】Java从单体到微服务打造房产销售平台(九) - 微服务架构的优势
最新文章
- 互联网协议 — PPP 点对点协议
- Pandas的DataFrame输出截断和省略问题
- 什么是Starter
- AT2165-[AGC006D]MedianPyramidHard【二分,贪心】
- 21南阳理工oj新生赛Round#5--这是一道防ak题
- eclipse设置黑色主题
- NVIDIA-cuda-cudnn下载地址
- Bat批处理脚本--常用命令
- 《嵌入式 – GD32开发实战指南》第11章 CPU的高级代理-DMA
- 小米笔试题(句子反转)
- 美国俚语:Keep your eyes peeled什么意思?_
- 修改下拉状态栏点击屏幕录制后出现ANR。禁用Hotspot tethering菜单下的 “Wi-Fi hotspot。默认系统语言为英文。
- 【圣诞快乐】用 C 语言画出一棵带有装饰的简易圣诞树
- php表格调整行间距,excel如何调整行距
- NormalEstimation法向量估计理论和代码---PCL源码笔记
- Linux: Top命令查询结果参数详解
- Oracle GoldenGate 文章集合
- Cesium绘制抛物线弧线
- 广东中考数学不允许使用计算机,上070821对苏州市数学中考两次禁用计算器的反思终稿.doc...
- 【】每日360题,2019.11.07日14点财会类考试习题答案