这5个错误在设计微服务架构的时候你一定要避开

来源: 云巴巴 2020-04-13 17:27:40

  到目前为止,大多数企业开发工作人员已听说了微服务的种种好处,不过,真正通过将现有技术应用程序转换成微服务体系架构以“迁移整体式系统”时,你可能会发现设计一个有效的微服务架构困难重重。开发社区没有花大量的时间来讨论如何设计,而是讨论为什么采用微服务架构。

  本文主要介绍了设计成功的微服务架构的几个优秀社会实践,我们不会介绍开发或部署微服务,而是通过讨论计划使用微服务系统架构时应避免的常见错误。

这5个错误在设计微服务架构的时候你一定要避开

1. 痴迷于每项功能有一个服务
  有效对于大多数开发人员描述的微服务架构,他们会告诉你的应用程序功能的各个方面应该由不同的微服务支持。例如支付应用程序,认证应该是一个微处理服务,支付是另一个微服务进行处理,前端又是一个微服务运行,另一个存储和检索数据,等等。
  主要的应用程序设计为分配给不同的微服务功能通常是一个好主意。但是这个基本原则很容易过犹不及,往往会阻碍设计进行有效的微服务系统架构。
  有时,区别一项功能与另一项功能的界线很模糊, 例如,您是否应该将用户注册视为与用户身份验证不同的功能,因此为每个功能创建单独的微服务?如果存储在多个位置的应用程序数据,每个位置都应该有自己的微服务?还是应该只有一个数据服务来处理所有的位置?
  这些问题的答案是,这可能无关紧要。 找出一个应用程序将有多少微服务,以及它将处理哪些功能。 如果你花了太多的时间来找出如何在应用程序中分割不同的任务,那么它的工作效率就不会很有效。
2. 微服务做得过小
  同样,设计微服务系统架构使每个微服务过小。因此我们需要企业众多微服务来组成整个应用程序是常见的错误。
  开发工作人员之所以遇到这个陷阱,是由于没有他们可以认为微服务越小越好,从某种意义上可以说是对的——将大型企业应用系统程序分成较小的离散单元是为应用程序不断提高可扩展性和可靠性的一种方法。
  但是,如果微服务变得太小,开发和部署微服务的成本将在以后显著增加。每个服务都需要有自己的开发和部署管道(更不用说单独监控,个人日志和安全操作了)。
  因此,虽然你确实我们希望微服务小点,但不应该选择过小,也不应该让应用系统程序含有太多的微服务。 一般情况下,如果您的应用程序由十几个微服务组成,每个微服务可能太小,则应该合并微服务,以不同的方式设计体系结构。
3. 需要特定的部署解决方案
  如今的常见做法是通过容器来部署微服务——通常借助OpenShift或另一种基于Kubernetes的编排平台。
  但几年后还会是这样吗? 我不知道。 部署技术在不断地更新,很难知道哪种部署解决方案对您的微服务应用程序来说是最合理的。
  因此,设计微服务架构的方式需要特定类型的部署技术是错误的。你不应该让自己依赖Kubernetes、甚至普通的容器才能部署应用程序,而是应设计一种可以在各种基础架构上、甚至可以在各种操作系统上运行的架构。
4. 要求同时更新所有微服务
  有时候你看到微服务架构的错误要求:如果一个微服务更新应用,同时也要更新(或至少是重新启动)其他微服务。
  如果从整体式系统的角度来看,这种想法很自然,但在微服务方面,这种做法意味着你是在自找麻烦。微服务的目的一方面是在不影响其他部分的情况下,更新、扩展或重新启动应用程序的某些重要部分。
  因此,如果改变微服务的状态也意味着改变其他微服务的状态,那么您将失去微服务带来的灵活性。也更难以持续交付,因为万一推动服务升级,你无法做到不影响其他服务。
  另一方面,你的微服务不应太紧密地耦合在一起。 在设计结构时尽量避免这种情况:如果您依赖的另一个服务没有运行,则服务无法运行。
5. 忽视日志
  设计微服务系统架构时要避免的最后一个陷阱是忽视日志。
  这个错误很容易被忽视, 当你为每个微服务编写代码时,你以为在以后搞清楚日志,或者你能够到一个微服务环境部署日志代理,它将能够收集你需要的所有数据。
  最好从一开始就将日志合并到微服务架构中。在许多情况下,这意味着微服务来自其它微服务收集日志数据创建的。然而,在其他情况下,每个服务可以开展自己的微测井,数据重定向到一个中心位置。
  无论哪种战略目标应该是确保微服务架构有利于从整个应用程序的日志数据的收集,并把它的中心位置分析和存储。

结论

  设计微服务时没有一个一成不变的规定。 然而,作为一般的指导方针,上述原则将帮助您规划一个微服务体系结构:提供微服务应该具有的所有好处,而不会遇到设计不当的微服务体系结构给开发人员和IT团队带来的麻烦。

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里!

 

评论列表

为你推荐

这5种场景不建议你采用微服务架构

这5种场景不建议你采用微服务架构

在这个世界上没有什么事情是绝对正确的,微服务也不例外,在里,我们着重讨论在设计或重构技术应用程序时,哪些场景可以使用微服务,哪些场景要避免使用微服务。 首先,我们要了解什么是微服务能力以及微服务有哪些发展优势。

2020-04-13 17:35:36

云计算中的微服务架构到底是什么?

云计算中的微服务架构到底是什么?

微服务系统架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间可以相互协调、互相配合,为用户发展提供最终价值,每个服务都在自己的独立进程中运行,在服务和服务之间有一个轻量级的通信机制。 每个服务都围绕着具体的业务进行构建。

2020-04-13 17:31:23

DevOps的“成长历程”——关于DevOps的发展介绍

DevOps的“成长历程”——关于DevOps的发展介绍

DevOps从诞生之初到现在都经历了什么?下面我们对DevOps的发展做简要介绍。

2020-04-14 17:44:06

灵雀云应邀出席2019思杰高峰论坛,详解微服务落地最佳实践

灵雀云应邀出席2019思杰高峰论坛,详解微服务落地最佳实践

10月31日,“智慧中国 赋能未来”2019思杰高峰论坛在北京成功举办。大会聚焦数字技术如何重塑工作方式,并积极探索在多云环境下企业如何通过释放信息技术架构活力,获得组织敏捷性。

2020-01-15 14:33:31

你所不知道的——微服务和DevOps实践经验

你所不知道的——微服务和DevOps实践经验

从结绳记事到计算云,计算工具从简单进化到复杂,这都是改善生产和生活的表现。软件的未来看似光明,但却把人们拖进了充满泥泞的现实。

2020-04-13 17:59:28

微服务核心架构对于企业的利和弊

微服务核心架构对于企业的利和弊

最近几年,微服务大行其道, 在商业模式不完善,大规模流量的影响下,许多企业放弃了传统的单一结构,拥抱微服务。这种模式已经具备独立开发、独立部署、可扩展性、可重用性的优点的同时,也带来一个重要问题:开发、运维的复杂性不断提高以至于给人感觉微服务越来越不便管理

2020-04-13 18:06:10

严选云产品

售后宝装备制造业售后服务系统 售后宝装备制造业售后服务系统,建立以客户/设备为中心的数据库,奠定业务扩展基础,ITR服务过程全程受控,实现两个内外循环管理。建立备件与服务高效协同,提高备件供应效率,通过数据智能化改善业务管理运行。多渠道快速报修,服务信息快速查询,提升用户体验和效率。
蓝墙互联Julius成本管理系统 蓝墙互联Julius成本管理系统,全闭环管理,保障成本“算得清、控得住”,支持动态字段配置及字段计算公式配置及数据设定,支持系统消息提醒和邮件提醒,项目阶段可与目标成本阶段关联,实现数据上的业务关联。
太极法智易法律事务管理平台 太极法智易法律事务管理平台,利用大数据、人工智能、自然语言处理等多项核心技术构建企业上下贯通、业财一体和共享赋能的合同管理平台。实现“无采购不签约”、“无合同不支付不放货”、“收货收款必有对应合同”、“有合同预算必有合同决算”等功能。
腾讯云RayData地产可视化解决方案 Raydata智慧工地可视化分析平台基于大数据技术,帮助领导及业务人员创建数据与每个组织成员的连接与对话,高效实现业务与数据之间的连通交互,分权分层级直观地工地项目情况,灵活应对需求调整,领导基于批示加速决策,实现决策分析无处不在的实时动态管理。
百家云语言私域直播行业解决方案 百家云语言私域直播行业解决方案,为企业客户提供私有化的企业内部培训系统、内部培训课程、系统定制、培训定制等,助力企业构建数字化内训平台。 将丰富的文库资源上传至网校文库搭建企业知识库,实现资料共享,课后补充,提高学员学习效果。
ITC大型多功能厅会议系统方案 ITC大型多功能厅会议系统方案,支持PROFINET通信,支持多台 PLC之间以太网通信,人性化操作界面。分组变频切换控制输出。急停控制,检测线路故障,设备运行监测。

推荐视频

甄选10000+数字化产品 为您免费使用

申请试用