专栏首页首席架构师智库[微服务架构 ] 微服务- 生存还是毁灭!

[微服务架构 ] 微服务- 生存还是毁灭!

上周,我谈到了作为一系列微服务开发的产品技术架构。谈话几分钟后,很明显团队已经支付了微服务高级版,但没有明显的投资回报。这组微服务是由一个由10名工程师组成的团队构建的,所有服务都是用java实现的,并使用消息总线将必要的数据复制到共享postgres实例中的自己的模式中。虽然工程师可能最有意愿建立一个可以扩展的系统,但它立刻让我想起了Donald Knuth的名言,

过早优化是万恶之源

我认为团队会更有效率,如果系统被构建为具有良好模块性和服务之间松散耦合的整体系统,那么系统就不那么复杂了。

让我们看一下微服务架构的优缺点,从我自己的经验来看,我在SAP时为我们构建的产品采用了微服务架构。

释放灵活性

采用微服务使我们能够灵活地根据微服务中代码的成熟度和质量来决定哪些功能可以通过v1发布。另一方面,单片应用程序意味着延迟发布,直到我们把所有事情都弄好。

主题移交

虽然我不是世界各地分布式团队的忠实粉丝,但我们需要接受并继续前进,这是今天的商业现实。通过遍布三大洲(美国,德国和印度)的全球开发团队实施产品非常具有挑战性,但在微服务方面明确分离功能使我们能够灵活地在不同地点之间移动功能。由于团队不需要了解整个代码库以详细了解功能集的一小部分,因此主题切换非常易于管理。

规模

扩展单片应用程序(尤其是水平扩展)绝对是可能的,但并非应用程序的所有部分都可能从扩展中受益,因为吞吐量要求因产品的不同功能而异。微服务架构允许我们根据吞吐量要求扩展应用程序的不同部分,并有效利用可用资源。

自治

我非常相信团队的完全自主权,这与微服务架构相得益彰,因为团队之间的依赖关系减少到最小,并且通过定义良好的接口或API进行通信。团队完全自治的缺点是编程语言,框架,开发工具的动物园,一旦团队扩展到100人,就变得无法管理。虽然微服务架构鼓励多语言运行时,但我建议坚持几个运行时,几个框架以及一个基于一个工具集的构建和发布过程。

监测和支持

由于微服务按照定义分布在许多服务器(物理或虚拟)上以实现水平扩展,因此它们运行的平台应提供强大的监控和支持基础架构。监视和支持在调试和查找日志文件中的错误的根本原因方面由于缺少聚合每个产品的日志和跟踪文件的工具而变得非常麻烦。例如,支持工程师可能需要查看每个微服务的大量日志文件,以找出错误的根本原因。

构建和发布

在微服务部署的情况下,构建和发布过程的复杂性有时会使团队士气高涨,因为他们不断与构建作业和部署作业作斗争。对我们来说,缺乏构建,部署和发布自动化是一项挑战。照顾一个构建工作,一个代码扫描,每个服务就像放牧猫一样。如果有什么东西打破没有人通知。事实上,我们每个微服务都有多个构建作业 - 一个用于拉取请求,一个用于运行代码扫描和集成测试的主构建,另外一个可以发布到工件库中。完全自动化的构建和发布过程是微服务架构有效提高开发人员工作效率的关键。

安全

在微服务架构中获得安全性是一个真正的复杂性助推器。我们花了很多时间来确定基本的安全要求,例如身份验证和授权(特别是在服务到服务通信上下文中),因为每个微服务都运行在它自己的进程中,而不是整体结构。使用单一应用程序,处理安全性就像将spring安全库放入Web应用程序,创建spring-security.xml并向REST端点添加一些安全注释一样简单。使用微服务,使用JWT处理复杂的OAuth流并在服务之间传递令牌并非易事.

数据复制

最后,我认为在微服务方面最重要的权衡是关于是否复制数据的争论(特别是在大数据环境中)。关于如何复制数据的技术 - 消息总线,点对点REST API等是这个决定的简单后续。

通常,为微服务(有界上下文)获取服务边界非常困难。如果服务边界不正确,则会导致数据重复并增加服务之间的耦合。数据重复是一个很大的问题,特别是当微生物主要是分析性的并且需要依赖于或多或少相同的大数据集进行分析时。

在大数据分析环境中,我不是复合服务或复合API的忠实粉丝(我将其定义为需要处理大约数百万个数据点以满足请求 - 如排序,过滤)。复合REST API实现往往性能较慢,无法与DB的响应时间相匹配,DB是处理连接,聚合,过滤等事情的理想场所。

我们最终创建了一个数据服务,它创建了一个像依赖的平台,因为几乎所有其他微服务都依赖于这个服务来查询大数据集。必须在此层中实现任何新查询,这会降低新功能的开发速度。但查询响应时间对于应用程序来说至关重要,因此我们可以进行权衡。

生存还是毁灭 !

与所有软件架构一样,为您的产品采用或不使用微服务是一种权衡讨论和决策。

本文分享自微信公众号 - 首席架构师智库(jiagoushipro),作者:南极真君

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-10-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微服务与SOA架构(2)

    服务分类学 服务分类学指的是在某种架构下服务是如何归类的。有两种服务分类的基本类型:服务类型和业务领域。服务类型分类法会根据整个架构中服务所扮演的角色进行分类。...

    首席架构师智库
  • 「微服务架构」Google和eBay在构建微服务生态系统方面的深刻教训

    当你看到来自谷歌,Twitter,eBay和亚马逊的大规模系统时,他们的架构已演变成类似的东西:一组多语言微服务。

    首席架构师智库
  • 「微服务架构」七种微服务反模式

    流行语经常为进化的概念提供背景,并且需要一个良好的“标签”来促进对话。微服务是一个新的“标签”,它定义了我个人一直在发现和使用的领域。文章和会议描述了一些事情,...

    首席架构师智库
  • 微服务的一些概念

    传统的单体架构,把所有的功能都集中在一起,打包为一个war包,或者是可执行程序。部署的时候,需要部署一个完整的应用,升级时,也需要替换整个war包或是可执行程序...

    Tencent JCoder
  • 什么是微服务?

    微服务(Microservice)这个概念是2012年出现的,作为加快Web和移动应用程序开发进程的一种方法,2014年开始受到各方的关注,而2015年,可以说...

    分母为零
  • 程序员必须掌握的高薪技术—微服务架构的实施原理技术

    基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发、持续集成的流程。

    IT大咖说
  • 微服务 - 从想法到迈出第一步

    原文地址:https://codeburst.io/microservices-from-idea-to-starting-line-d6e8cd5e9bb4?...

    双愚
  • 七种微服务反模式

    流行术语为那些逐步形成的、需要一个好的“标签”来方便交流的概念提供了一个上下文。微服务就是这样的一个新“标签”,它定义了一个领域,这个领域我自己也发现了,并且...

    ★忆先★
  • 《istio实战指南》第1章 服务网格

    yeedomliu
  • 颠覆微服务认知:深入思考微服务的七个主流观点

    微服务架构现在已经成为了企业应用架构的必聊话题,本文沉淀了作者多年工作的所见所闻和实战思考,跳出纯技术的视角去思考架构,去看待微服务,保证利用现有的技术(工具)...

    用户2781897

扫码关注云+社区

领取腾讯云代金券