推荐阅读:
架构设计原则 - 高并发
使用 Canal 实现数据异构
MySQL中一条SQL语句是如何执行的?
阿里开源的分布式事务框架 Seata
ZooKeeper 并不适合做注册中心
微服务开发的首要挑战:
把大的、复杂的应用拆分为小的、自治的、可独立部署的模块。
如果没有正确的拆分,那么结果就是一堆浆糊,有着单体结构的缺点,和微服务结构的复杂度,可以称之为 分布式单体 。
幸运的是,Eric Evans 为领域驱动设计提出了大量的最佳实践和经验技巧,有3个核心思维:
开发团队要和业务部门、业务领域专家紧密合作。
架构师、开发人员、领域专家应该先做出战略设计:找出边界上下文、核心域、子域、上下文映射关系。
架构师、开发人员根据战略设计梳理出一套核心构造块:实体、值对象、聚合等等。
把一个大型系统划分为核心域、子域,再把核心域、子域映射为微服务,这样我们就可以得到一个理想的松耦合微服务体系。
微服务模块结构设计好了,下面一个重要问题就是怎么处理数据库,各个微服务是否共享数据库呢?
如果共享,将导致微服务之间紧耦合,违背了微服务的松耦合原则。数据库中一个小小的变动就需要各个团队同步修改。
如果每个微服务都有自己的数据库,那么微服务之间的数据交换将非常麻烦,就像打开了潘多拉魔盒,跑出一堆问题,例如在多个服务中管理事务。
所以,很多人主张共享数据库。
但是,微服务是持续的、长期的软件开发,每个微服务应该有其自己的数据库。
很多后端开发者轻视前端,认为太简单。
大多数架构师也是后端出来的,在架构设计中对前端不够重视。
导致现状就是,后端模块化做的很好,而前端还是一整坨。
前端单体结构和后端单体有一样的问题,所以前端也需要进行现代化的改造。
现在的 web 技术简单、强大,例如 web 组件、Angular/React。
每个微服务可以独立部署,是微服务架构的核心优势之一。
比如你的系统包含 100 个微服务,现在有一个需要更新,那么你可以只需要发布这一个,而另外 99 个不需要动。
这就需要 CI/CD 和 DevOps,如果没有这套自动化流程的话,就像拉着手刹开法拉利。
微服务架构简化了开发,但复杂了运维。
单体结构是非常便于监控的,但在微服务架构中,服务很多,而且通常是跑在容器中,对整个系统的监控就变得非常复杂。
需要把所有容器、机器中的日志聚合到一起。
幸运的是已经有成熟的解决方案,例如,使用 ELK/Splunk 处理日志,使用 Prometheus/App Dynamics 处理监控。
还有一个比较重要的方面:调用跟踪。
微服务间会产生级联调用,为了分析系统延迟,就需要测量每个服务的延迟, Zipkin/Jaeger 提供了这个能力。
微服务体系中,不同服务有不同的特性,例如有的服务是 CPU 密集型操作,使用 C++/Rust 比较合适;有的服务是做机器学习的,使用 Python 比较合适。
所以,可以使用不同的技术处理相应的需求,但是,一定要注意合理性,不要毫无根据的混合使用不同的技术。
想象一下,在一套系统中,有的微服务使用 Spring Boot + Kotlin+ React + MySQL,有的使用 JakartaEE + Java + Angular + PostgreSQL,有的使用 Scala + Play Framework + VueJS + Oracle。
这会不会让人很崩溃,太难维护了。
服务间的通信问题是微服务架构的重要挑战,比是否共享数据库那个问题还麻烦。
为了实现业务需求,需要多个微服务的协同工作,服务间需要进行数据交换,一个服务需要触发其他服务。
最简单的就是通过 REST 接口直接调用,但这种同步调用方式问题比较大。
例如 A -> B -> C -> D,这种多级调用主要的3个问题:
增加了系统延迟。
每个服务可能会故障,这就产生了级联性的错误。
服务间紧耦合。
最好是使用异步通信的方式,例如通过消息队列(如 kafka)、异步的 REST(ATOM)、CQRS。
很多人认为新项目应该使用单体结构,这样起步快,比微服务简单,当发展大了之后再改造为微服务。
然而,这个改造是非常困难的,因为单体中模块的耦合度太高了。
而且产品成熟后,对在线可用性要求很高,那个时候再改造的话,一定会中断产品运行。
Netflix 早期开发微服务时,主要使用 java 来开发,Netflix 开发出了很多优秀的库,如 Hystrix, Zuul ,很多公司都使用他们。
后来,包括 Netflix 在内的很多公司都发现 java 其实并不擅长微服务开发,例如 java 体积过于庞大。
Netflix 转向了 Polyglot,并停止了之前那些库的维护,这就让很多公司被动了。
所以,不要过度依赖特定语言的类库,可以使用更底层的基础框架,例如 Service Meshes 。
50 年前,Melvin Conway 发现公司的软件架构受限于其组织结构。
其实在现在,这个观点依然正确。
如果一个组织想使用微服务架构,那么就应该调整好团队的大小。
两个披萨饼原则:如果两个披萨不足以喂饱一个项目团队,那么这个团队可能就显得太大了。
而且,团队成员应该是多元化的,有前端、后端、测试、运维。
只有高层领导者转变思维方式,微服务架构才有可能发挥作用。
翻译整理自:
https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee20