成功准备微服务的5个步骤

原文作者:Kristijan Arsov

原文地址:https://medium.com/@kikchee/5-steps-to-successfully-prepare-for-microservices-cd5205204ec2?source=search_post


设计应该始终在开发之前!

微服务一直是一个热门话题 - 数百次会议已经举办了,网络研讨会和媒体都是关于这个主题的。到目前为止,你会认为每个人都已经知道他们提供的所有好处,以及他们带来的所有风险。然而,许多组织在没有事先准备的情况下就已经进入了这个趋势。在实现这种类型的体系结构时,这自然导致了许多失败。

一位智者曾经说过:

“在企业中使用的任何技术的第一条规则是应用于有效操作的自动化将放大效率。第二,将自动化应用于效率低下的操作将放大效率低下。“ - 比尔盖茨

我相信这个理念也适用于微服务。没有为这个过渡做好准备很可能会导致失败。这就是为什么在本文中,我将介绍为准备实现微服务体系结构需要遵循的5个步骤

1.从绘图开始

许多开发人员在开发某种微服务时犯了直接编码的错误。这可能是你可以犯的最大错误。是的,也许你会成功地提供一项服务; 然而,随着他们人数的增加,整个事情将变得一团糟。

与其他需要创建的产品一样,流程必须从设计开始。通过设计,我的意思是和团队一起围坐在桌子旁,把服务写在纸上(或者白板上)。首先确定正在构建的应用程序的主要功能。然后,通过自顶向下的方法,将它分解为最小的单元。最后,展示所有这些不同的部分之间的相互联系。这些功能将成为您的微服务。

纸张可以承受很多变化

例如,在书评应用程序中,主要功能是不同书籍的比较。但是,必须开发许多其他功能,例如创建用户配置文件,评级,评论,书籍数据库等。识别每一个功能对于将它们捕获到微服务中至关重要。

这个过程将持续超过一天,并需要多次迭代直到完善。当然,您需要来自不同部门的许多人的意见,以获得不同的观点和意见,并确保您不会遗漏系统的任何功能。

2.微服务不是组织单位

根据公司的组织单位来定义微服务似乎很自然。如果你正在构建一个单一的应用程序,这看起来可能是一个合适的解决方案。但是,在实施这种体系结构时,可能是一个错误的决定。

也许它适用于销售部门或客户服务,但是许多组织只有一个单元来处理所有的数据库。因此,为所有数据库创建一个微服务将导致一个单点故障。这是微服务的一个关键特性-  不会有单点故障!

您希望通过服务呈现的一些功能可能会延伸到几个组织部门。或者,您可能需要为单个部门构建许多微服务。最后,您应该将架构的重点放在您想要提供的功能上,而不是您公司的组织结构上。

3.创建合适的团队结构

切换到完全不同的架构结构肯定会使得公司管理和监控活动发生变化。前两步的重点在于设计应用程序以向最终用户提供正确的功能。现在,是时候确保您为新架构提供适当的操作支持了。

您将不得不放弃旧的部门结构,将团队集中在特定的微服务上。这意味着每一个团队将由不同的成员有不同的技能系统分析师等用户体验/ UI设计人员,后端和前端开发者,等等。这样,团队负责项目从端到端(microservice)——从开发和部署操作,监视和管理。这反过来又会增加他们创造自己觉得属于自己的产品的动机。

团队如何在不同的体系结构中定义

团队的规模将由公司/项目的总规模决定; 然而,专家建议,理想的规模是每支团队8-10人。此外,与整体架构不同,微服务体系结构允许您在业务增长时扩展团队规模。

当然,所有团队都将积极协作,完成整个项目。这就引出了这种结构的主要好处——将最终产品更快地交付给市场。

4.性能和可靠性也很重要

切换到微服务体系结构背后的整个想法是创建一个性能优于整体的最终产品,更可靠(即停机风险更低),当然,可以更快地交付到市场。

将性能作为设计过程的一部分处理是很重要的,,以确保尽早考虑任何潜在问题。通常情况下,微服务设计主要集中在功能上这一块。但是,如果服务第一次收到更大的负载时崩溃或明显减速,那么该服务将变得毫无用处。当底层资源失败时,每个服务都应该有两到三个可选的机制来继续运行,如果一个服务在可接受的时间范围内没有响应,那么它应该快速循环。

考虑如何预先为更大的负载变化准备服务,将有助于应用程序抵御真正的挑战,使您在市场上具有竞争优势。

5.提前计划变更

忽略应用程序更改是不可能的。开发人员不断地添加和删除功能,修改代码,替换应用程序的核心元素等等。微服务应用程序更是如此。实际上,更正确的说法是,微服务正在不断发展。

总是想着未来!

当您每天处理几次代码更新时,最好接受更改是常量,而不是偶尔中断到稳定状态。一旦您认识到这一点,您就会意识到,从一开始就集成更改所需的灵活性是很重要的。确保您的应用程序始终正常工作的一种方法是准备服务API,以便各个微服务可以继续相互交互,即使它们发生更改。此外,您应该包含版本控制,以便允许服务包括旧的和新的服务接口。

另一方面,数据存储的演变更具挑战性。不断发展的数据库方案在传统上支持新功能一直是升级应用程序中最困难的部分,而微服务并没有让它变得更容易。然而,NoSQL数据库的新技术在添加新字段而不破坏现有结构方面更加灵活。如果您期望您的数据存储需求不断发展(谁不希望呢?),您应该将可演化的数据存储作为微服务设计工作的一部分。

结论

我们一致认同,为向微服务体系结构的过渡做好准备是整个项目成功的关键因素。只有通过仔细的规划、创新的设计思维以及适当的操作和管理结构-您才能获微服务提供的所有好处

本文的版权归 阿小庆 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

动手为王 - 整合迁移与数据恢复实践

作者简介: ? 李真旭(Roger) 云和恩墨西北区技术总监,Oracle ACE, ACOUG 核心专家 对于数据库升级迁移,这两年是一个非常热门的话题,尤其...

3335
来自专栏云计算D1net

云计算的乐高积木Docker如何重构应用程序开发

Docker的发展势态如同森林大火,势不可挡。这项新型的Linux容器技术引燃了一路上的一切东西,面对其迅猛发展的势头,我们许多人还没有回过神来。Docker不...

2384
来自专栏后端技术探索

漫谈大型网站架构

作者介绍:陈康贤(花名龙隆),淘宝技术部技术专家,著有《大型分布式网站架构设计与实践》一书,在分布式系统架构设计、高并发系统设计、系统稳定性保障等领域积累了较为...

521
来自专栏开源项目

自建 GitLab 似乎很简单?这些坑也许你不知道

4914
来自专栏Forrest随想录

运维需不需要懂产品和运营呢?

继续接上文,我们制定或约定了架构标准,接下来就是架构的实施过程,架构实施应该怎么理解呢?我大致列一下过程应该就比较清晰了:

555
来自专栏ThoughtWorks

数字化企业的API架构治理

在前文中我们说到,传统企业在逐步建设自己的数字平台过程中,需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱...

2594
来自专栏云计算D1net

提升云计算体验 采用四个小工具

云计算的出现改变了传统的业务模式。但最近频频出再安全漏洞事件,却也使企业在使用云计算技术上生了胆怯,尤其是这些安全事件还有上升的趋势,据美国电信运营商Veriz...

3365
来自专栏ThoughtWorks

服务拆分与架构演进|洞见

本文首发于InfoQ: http://www.infoq.com/cn/articles/service-split-and-architecture-evol...

3264
来自专栏ThoughtWorks

项目实施DevOps时,我们是如何做测试的 | 洞见

正如我们所知,DevOps最近几年很风靡,很多企业正在如火如荼的推行它。然而,你可曾想过,从传统到敏捷、再到DevOps,开发模式的不断革新对测试提出了怎样的挑...

2725
来自专栏云计算D1net

无服务器:云计算下一步的演变

行业专家在世界各地的会议中,以及与同事,客户,合作伙伴的沟通交流中,感觉到了业界对无服务器计算的困惑。 人们对于这种新架构如何革新组织处理开发和创新的方式,期...

28211

扫码关注云+社区