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

推荐阅读:前端

1. 领域驱动设计

微服务开发的首要挑战:java

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

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

幸运的是,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.co...

相关文章
相关标签/搜索