专栏首页性能与架构有效的微服务:10 个最佳实践

有效的微服务:10 个最佳实践

1. 领域驱动设计

微服务开发的首要挑战:

把大的、复杂的应用拆分为小的、自治的、可独立部署的模块。

如果没有正确的拆分,那么结果就是一堆浆糊,有着单体结构的缺点,和微服务结构的复杂度,可以称之为分布式单体

幸运的是,Eric Evans 为领域驱动设计提出了大量的最佳实践和经验技巧,有3个核心思维:

  • 开发团队要和业务部门、业务领域专家紧密合作。
  • 架构师、开发人员、领域专家应该先做出战略设计:找出边界上下文、核心域、子域、上下文映射关系。
  • 架构师、开发人员根据战略设计梳理出一套核心构造块:实体、值对象、聚合等等。

把一个大型系统划分为核心域、子域,再把核心域、子域映射为微服务,这样我们就可以得到一个理想的松耦合微服务体系。

2. 每个微服务一个数据库

微服务模块结构设计好了,下面一个重要问题就是怎么处理数据库,各个微服务是否共享数据库呢?

如果共享,将导致微服务之间紧耦合,违背了微服务的松耦合原则。数据库中一个小小的变动就需要各个团队同步修改。

如果每个微服务都有自己的数据库,那么微服务之间的数据交换将非常麻烦,就像打开了潘多拉魔盒,跑出一堆问题,例如在多个服务中管理事务。

所以,很多人主张共享数据库。

但是,微服务是持续的、长期的软件开发,每个微服务应该有其自己的数据库。

3. 微前端

很多后端开发者轻视前端,认为太简单。

大多数架构师也是后端出来的,在架构设计中对前端不够重视。

导致现状就是,后端模块化做的很好,而前端还是一整坨。

前端单体结构和后端单体有一样的问题,所以前端也需要进行现代化的改造。

现在的 web 技术简单、强大,例如 web 组件、Angular/React。

4. 持续交付

每个微服务可以独立部署,是微服务架构的核心优势之一。

比如你的系统包含 100 个微服务,现在有一个需要更新,那么你可以只需要发布这一个,而另外 99 个不需要动。

这就需要 CI/CD 和 DevOps,如果没有这套自动化流程的话,就像拉着手刹开法拉利。

5. 可观察性

微服务架构简化了开发,但复杂了运维。

单体结构是非常便于监控的,但在微服务架构中,服务很多,而且通常是跑在容器中,对整个系统的监控就变得非常复杂。

需要把所有容器、机器中的日志聚合到一起。

幸运的是已经有成熟的解决方案,例如,使用 ELK/Splunk 处理日志,使用 Prometheus/App Dynamics 处理监控。

还有一个比较重要的方面:调用跟踪。

微服务间会产生级联调用,为了分析系统延迟,就需要测量每个服务的延迟,Zipkin/Jaeger 提供了这个能力。

6. 统一技术栈

微服务体系中,不同服务有不同的特性,例如有的服务是 CPU 密集型操作,使用 C++/Rust 比较合适;有的服务是做机器学习的,使用 Python 比较合适。

所以,可以使用不同的技术处理相应的需求,但是,一定要注意合理性,不要毫无根据的混合使用不同的技术。

想象一下,在一套系统中,有的微服务使用 Spring Boot + Kotlin+ React + MySQL,有的使用 JakartaEE + Java + Angular + PostgreSQL,有的使用 Scala + Play Framework + VueJS + Oracle。

这会不会让人很崩溃,太难维护了。

7. 异步通信

服务间的通信问题是微服务架构的重要挑战,比是否共享数据库那个问题还麻烦。

为了实现业务需求,需要多个微服务的协同工作,服务间需要进行数据交换,一个服务需要触发其他服务。

最简单的就是通过 REST 接口直接调用,但这种同步调用方式问题比较大。

例如 A -> B -> C -> D,这种多级调用主要的3个问题:

  • 增加了系统延迟。
  • 每个服务可能会故障,这就产生了级联性的错误。
  • 服务间紧耦合。

最好是使用异步通信的方式,例如通过消息队列(如 kafka)、异步的 REST(ATOM)、CQRS。

8. 微服务优先

很多人认为新项目应该使用单体结构,这样起步快,比微服务简单,当发展大了之后再改造为微服务。

然而,这个改造是非常困难的,因为单体中模块的耦合度太高了。

而且产品成熟后,对在线可用性要求很高,那个时候再改造的话,一定会中断产品运行。

9. 基础设施优于类库

Netflix 早期开发微服务时,主要使用 java 来开发,Netflix 开发出了很多优秀的库,如 Hystrix, Zuul,很多公司都使用他们。

后来,包括 Netflix 在内的很多公司都发现 java 其实并不擅长微服务开发,例如 java 体积过于庞大。

Netflix 转向了 Polyglot,并停止了之前那些库的维护,这就让很多公司被动了。

所以,不要过度依赖特定语言的类库,可以使用更底层的基础框架,例如 Service Meshes

10. 组织考虑

50 年前,Melvin Conway 发现公司的软件架构受限于其组织结构。

其实在现在,这个观点依然正确。

如果一个组织想使用微服务架构,那么就应该调整好团队的大小。

两个披萨饼原则:如果两个披萨不足以喂饱一个项目团队,那么这个团队可能就显得太大了。

而且,团队成员应该是多元化的,有前端、后端、测试、运维。

只有高层领导者转变思维方式,微服务架构才有可能发挥作用。

翻译整理自:

https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee20

本文分享自微信公众号 - 性能与架构(yogoup),作者:杜亦舒

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

原始发表时间:2020-01-13

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微服务架构

    微服务产生的背景 在网站初期,网站的架构比较简单,通常把所有代码统一打包部署的服务器上 以java项目为例,例如有5个程序员,他们各自开发自己的功能模块,然后...

    dys
  • Medium 微服务策略

    微服务架构的目标是帮助技术团队更快、更安全、更高质量的推动产品,服务解耦可以让团队快速迭代,对系统的影响最小。

    dys
  • 微服务架构中如何构建一个数据报告服务?

    在微服务架构中,每个微服务负责自己的数据库,微服务A是不允许直接连接微服务B的数据库进行操作的。

    dys
  • 谈谈服务治理

    静儿
  • 转换到微服务架构时需要考虑的7件事

    每当您的团队从头开始开发一个新的应用程序时,不需要陷入多年前做出的过时决策和继承技术债时,感觉很好。现在开发新应用的大多数团队可能会选择使用Docker,并采用...

    程序你好
  • 漫谈微服务

    微服务是一种软件架构风格,一种架构模式,提倡将单体应用划分为一组小的服务,服务之间互相协调,互相配合,为用户提供最终价值。

    用户2937493
  • 快速学习-系统架构演变

    随着互联网的发展,网站应用的规模不断扩大。需求的激增,带来的是技术上的压力。系统架构也因此也不断的演进、升级、迭代。从单一应用,到垂直拆分,到分布式服务,到SO...

    cwl_java
  • 微服务的鉴定与思考

    微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能。举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: 接收库存 计算新...

    CSDN技术头条
  • 颠覆微服务认知:深入思考微服务的七个主流观点

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

    用户2781897
  • 小师妹对IT服务安全的思考

    目前国内外并没有任何标准或文献对IT服务安全进行规范。因此我写这篇文章的目的一是分享我自己对服务安全的思考,二是想听听各位在IT服务项目上积累了多年实践经验的前...

    FB客服

扫码关注云+社区

领取腾讯云代金券