专栏首页博文视点Broadview为什么你会觉得微服务架构很别扭

为什么你会觉得微服务架构很别扭

小编说:很多系统迁移到微服务架构之后,并没有明显感觉到微服务架构带来的优势,反而觉得带来了更高的复杂度,在《持续演进的Cloud Native》书中作者总结了七种微服务架构没能发挥出固有优势的原因,看看自己“中枪”了没!

  • 1、用传统方式构建微服务

微服务架构和传统的架构方式思路完全不一样。例如传统方式实现高可用,更相信流程,更相信KPI对人的影响,因此流程需要让更多的人去测试,制定更严格的发布流程。

而微服务架构强调的是自动化发布、灰度发布、Design For Failure、自动化测试、故障隔离、自愈。很多失败的案例以传统的方式去构建微服务架构,一切都没有转变,只是把服务拆开,根本无法享受微服务架构带来的便利,反而因此遇到了更多麻烦。最明显的是对开发人员的影响,他们质疑微服务架构是否适合自己的业务场景,而一个充满质疑的团队是不可能具备强大战斗力的。

  • 2、组织结构不变

如果要充分发挥微服务架构的优势,组织结构必须发生转变,构建和微服务配套的小团队,并且让他们拥有绝对的自主权。实际上,相当一部分实施微服务架构的团队都没有做到这一点,因为组织结构总是涉及利益。比较典型的问题是,小团队不需要团队以外的任何人来批准是否上线,架构如何演进,使用什么数据库。如果小团队没有权利,任何变动都要等待高层进行决策,就会形成决策瓶颈点,导致效率低下,这违背了微服务架构的初衷,团队成员也会因此失去主动性。

  • 3、习惯于领导安排工作

传统的研发模式严重依赖流程,原因是没有人愿意承担责任,所有人都把责任推到流程上。微服务架构和敏捷开发流程是天作之合,传统研发模式需要领导批准,然后由团队负责人直接分解任务、定工时、安排任务负责人,而按照敏捷开发流程,开发计划应该是团队决定的,任务自主认领。精英化团队绝不仅仅是团队人数更少,人员能力更强这么简单,这只是表面上的,更重要的是责任感和主观能动性以及信任!

某公司CEO 曾经说过这样一件事情,员工把请假流程提给“我”,让“我”审批,但是“我”根本没有审批的必要,因为你随便说一个理由“我”都不可能拒绝,就算拒绝了,下回会来一个更难以拒绝的理由。后来公司所有的请假都不需要审批了,只要在群里发一条消息,让相关同事知道就可以了。

  • 4、纠结如何拆分服务

不理解微服务架构的人,通常从字面理解,他们认为微服务架构的重中之重就是服务拆分。

到底拆分多细?与其浪费更多的时间思考这个问题,不如先拆出几个服务运行一下,感受一下。架构是一个持续的过程,有时候很难从技术角度完全解释清楚。

另一个错误是一次性拆分,不能改变。由于技术人员对业务领域知识的理解不断加深,业务逻辑有可能运行一段时间也会转变,这时候改变是不可避免的。重新合并、划分,是一个正常的演变过程。架构是动态的,不是静态的。

  • 5、以大规模拆分服务开始

微服务架构需要一个适应过程,持续拆分效果更佳。如果从大规模拆分服务开始,需要具备三个条件,否则可能会遇到相当多的麻烦。

  • 团队有微服务架构经验。
  • 已具备微服务架构的先决条件,包括自动化的研发环境、全面的健康检查、必要的公共服务及框架,以及敏捷基础设施。
  • 业务目标非常明确,已经可以预期未来的规模,业务几乎无变化。
  • 6、高估架构的移植性

架构是一门艺术,不是随随便便复制一下就可以的,Google、Amazon、Facebook 的架构问世已经很长时间了,研发人员跳槽这么频繁,但是没有哪个公司能模仿好。MySQL 开源了这么多年,放到不同人的手里,结果完全不一样。实际上实施微服务架构在一个业务场景中的优势在另一个场景中很可能会变成一种劣势。如果你仔细研究就会发现,大多数公司实施的微服务架构就跟各个公司的管理制度一样各不相同。很多公司为了显示自己的架构有多厉害而实施微服务架构,最终只会害了团队,因为只把精力放在微服务架构上,可能就减少了对业务实现、用户体验的关注。

  • 7、从来没有做过微服务架构的人领导你完成迁移

如果转型的团队由没有经验的人来领导,那么结果就是只关注表面,拆了多少服务、服务粒度、服务注册发现、负载均衡、调用链分析,而隐藏的各种性能问题、扩展性问题、可用性问题都没有得到足够的关注。如果只是从几个服务拆分开始积累经验还好,一旦大规模拆分,就会让整个团队都质疑微服务架构的意义。架构是需要实践的,不要以为看几篇文章就得到了架构的真谛,细节会“杀死”团队。

本文选自《持续演进的Cloud Native:云原生架构下微服务最佳实践》,作者王启军。

作者从全局视角出发,全面阐释Cloud Native 的关键技术,以及其衍生出来的工具、团队文化等核心要素,对于正在部署微服务架构或开展云原生业务的企业和组织而言,终于有了面向落地的务实参考和全面指导。

本文分享自微信公众号 - 博文视点Broadview(bvbooks)

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

原始发表时间:2018-12-06

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 移动开发架构选型大PK

    架构设计在现今已经成为软件开发必不可少的环节,而架构学习和架构选型往往是一个困难的“工程”。若有一天我们想要改善现有软件的架构模式,或对架构的选择感到迷茫,我们...

    博文视点Broadview
  • 单体架构与微服务架构对比,为什么采用微服务架构

    就像很难用一个绝对的方式去判断架构好坏一样,在大多数场景下,我们也很难从一个外部的视角去判断服务拆分粒度的合理性,需要对上下文非常了解才能做出一个好决策。例如,...

    博文视点Broadview
  • “架构”到底指什么

    对于技术人员来说,“架构”是一个再常见不过的词了:我们会给新员工介绍整个系统的架构,参加架构设计评审,学习业界开源系统(例如,MySQL、Hadoop)的架构,...

    博文视点Broadview
  • 模块架构不是软件成功的“决定因素”

    【本文是09年的一篇旧文,出于某些原因,对原文内容有删减,在这里整理后重新发表】 前言 感谢XXX对我们技术,对我们公司产品提出这些意见,我们公司卖的是软件...

    用户1177503
  • 移动开发架构选型大PK

    架构设计在现今已经成为软件开发必不可少的环节,而架构学习和架构选型往往是一个困难的“工程”。若有一天我们想要改善现有软件的架构模式,或对架构的选择感到迷茫,我们...

    博文视点Broadview
  • 软件架构入门

    合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位(architect),只有资深程序员才可以担任。

    lyb-geek
  • 数据科学家应该知道的10个深度学习的高级架构!

    随着深度学习不断地产生新进展,要跟上时代的脚步变得异常困难。几乎每天都有创新,或是产生一种新的深度学习的应用。 这篇文章包含了最近深度学习的一些进展。为了保持文...

    AiTechYun
  • 阿里p7专家:年薪50w+ 只因做到了这几点......

    1. 学校不错,一般都是985,211,如果学校一般,那么你下面的2和3满足的话,问题也不大。

    java思维导图
  • 如何进行安全架构规划

    大数据文摘
  • 什么才是真正的架构设计?

    在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概...

    xcbeyond

扫码关注云+社区

领取腾讯云代金券