java架构师指南:微服务架构搭建前需要做哪些准备

    搭建微服务架构绝非易事。我们不仅必须对微服务的概念有深刻的了解,而且还必须研究大量的技术工具并掌握它们的优缺点。最后,我们需要结合技术团队对技术的理解。选择最合适的技术选择。这...

    搭建微服务架构绝非易事。我们不仅必须对微服务的概念有深刻的了解,而且还必须研究大量的技术工具并掌握它们的优缺点。最后,我们需要结合技术团队对技术的理解。选择最合适的技术选择。这些纯粹的技术技术工具只是微服务的基础架构。我们还需要围绕该基础架构上的实际业务场景合理地划分微服务的边界。我们将在本节中介绍微服务的冰山模型。您将从此冰山中看到微服务架构的整体图。然后,我们将深入研究冰山之下的世界,并探索八个微服​​务基础设施中心。最后,我们将返回将介绍用于细分微服务边界的一些原理和技术。

attachments-2020-09-PiAQwwaz5f64a8848e4fa.png

    我们现在就从微服务冰山模型开始吧,这座冰山似乎比我们想象中的要大很多。

    1. 认识微服务架构冰山模型

    有些人认为,使用了SpringBoot开发框架就是拥有了微服务,其实这样的认识是不正确的。SpringBoot只是一款微服务的开发框架,而且仅能用于Java应用程序中,毫无疑问,它只是微服务的冰山一角。此外,我们建议大家结合自身的业务场景,选择更为合适的编程语言以及开发框架来实现微服务,而不要拘泥于一种编程语言。

    还有一些人认为,用上了Docker就进入了微服务时代,其实这样的认识也是不正确的。Docker只是一种封装微服务应用程序的容器化技术,它改变了应用程序的交付方式,也加速了微服务架构的落地速度。可以肯定地说,如果没有Docker容器技术,或许今天我们无法听到微服务的概念。

    如果将微服务架构中所涉及的技术栈比喻为一座冰山的话,那么冰山之上最显而易见的部分就是微服务的开发框架与容器技术了,SpringBoot与Docker都属于冰山之上的技术。

    冰山之下到底有哪些技术呢?

    我们认为冰山之下的技术是整个微服务架构的基石,它们构成了整个微服务架构的基础设施。比如我们在上册中学习的ZooKeeper服务注册表、Node.js服务网关、Jenkins持续部署系统等,它们都属于冰山之下的部分。

    由于服务注册表集中管理了微服务相关的服务配置,因此我们也将它称为“注册中心”;由于服务网关是前端应用程序的唯一入口,因此我们也将其称为“调用中心”;同样,我们也将持续部署系统称为“部署中心”。这些中心都汇集在微服务冰山模型之下,除此之外,还有其他功能的中心,这些中心共同构成了微服务的基础设施。

    2. 冰山下的微服务基础设施

    冰山下的微服务基础设施,实际包括了八大中心。

    (1)注册中心:用于注册微服务相关配置信息的中心,我们选用ZooKeeper实现。

    (2)调用中心:用于提供给前端调用的统一入口,我们选用Node.js实现。

    (3)部署中心:用于编译并打包微服务源码并将其部署到Docker引擎中,我们选用Jenkins实现。

    (4)日志中心:用于收集并管理微服务应用程序中产生的日志,第2章中将详细介绍。

    (5)监控中心:用于监控微服务的实时运行状况,第3章中将详细介绍。

    (6)追踪中心:用于最终微服务的调用轨迹,第3章中将详细介绍。

    (7)消息中心:用于解耦微服务之间的调用关系,第5章中将详细介绍。

    (8)配置中心:用于管理微服务应用程序所需的配置参数,第7章中将详细介绍。

    也许大家看到以上八大中心后会产生一些疑惑:很多人说微服务是去中心化的,为何我们还要提供这些中心呢?

    我们认为,中心分为两类:一类是含有业务意义的中心;另一类是不含业务意义的中心(只是技术层面的中心)。

    在微服务架构中我们应该去除的是含有业务意义的中心,而不是去除技术层面上的广义中心。比如,我们所设计的调用中心内部是不可能带有任何业务流程的,它只是一个纯技术层面的框架。对于其他中心也是如此,绝对不含有任何的业务,否则我们就应该将其去除。

    3. 根据业务切分微服务边界

    凡是学习过微服务的人都知道,我们需要根据业务来切分微服务边界。道理可能大家都懂,但或许仍然不知道应该怎么去做。例如,切分微服务边界有哪些关键性步骤,以及包含哪些重要性原则?

    经过大量的微服务实践,我们总结了以下五个步骤,可帮助大家有效地切分微服务边界。

    第一步:梳理业务流程。

    在切分微服务之前,我们要做的第一件事情就是梳理业务流程。不妨找业务专家咨询,通过与他们沟通从而了解真实的业务流程,并将其绘制成流程图。对于过于复杂的业务流程,我们也可单独绘制流程图,并增加相关的流程说明。当然也能提供相应的状态图,用于说明业务流程中所涉及状态的变化过程。

    花再多时间去分析业务流程都不过分,现在所花的每一分钟都是相当值得的。

    第二步:抽取公共服务。

    在业务流程中与业务不太相关的部分,我们可考虑将其剥离出来,并形成公共服务。例如,邮件发送、文件上传、其他第三方接口等。每种公共服务都对应一个微服务,每个微服务都有相关API,每个API都有自己的输入与输出。这些API一定要形成文档,以便其他服务调用。

    一般情况下,抽取的公共服务都不太会变化,我们一定要想办法将不变的东西从可变的世界中抽取出来。

    第三步:定义业务服务。

    当公共服务抽取完毕后,业务流程中剩下来的部分就是业务服务了。建议刚开始实施微服务时,不要将业务服务的边界切得太细,可以考虑先“大切几块”,但需要确保每个服务之间尽量不要有依赖关系。换句话说,每个服务都是独立的,虽然此时服务的块头可能比较大。

    我们先确保这些大块头服务可以运行在微服务基础设施上,再不断将它们进行细化,拆解为更小的服务。

    第四步:设计数据模型。

    深入到每个业务服务中,我们首先要做的是定义它底层所涉及的数据模型,也称为“领域模型”。此时会涉及数据库表结构设计,以及数据模型与关系设计。在数据层面上的设计是至关重要的,如果该部分设计得不到位,将增加后期实现微服务的成本。

    数据模型的设计同样也需要进行文档化,这些文档将指导后端工程师顺利地完成微服务实现。

    第五步:定义服务接口。

    底层的数据模型设计完毕后,我们将视角转换到顶层的服务接口上。服务接口实际上就是一组API,这些API需做到职责单一,而且需要通过名称就能识别出它的业务含义。建议确保每个API的命名是全局唯一的,也建议每个API都有各自的版本号,版本号可以用自增长的方式来体现。

    服务接口也需要进行文档化,这些文档一般由后端工程师编写,并提供给前端与测试工程师阅读。

推荐阅读:java架构师指南之架构师的工作流程

  • 发表于 2020-09-18 20:32
  • 阅读 ( 237 )
  • 分类:技术干货

0 条评论

请先 登录 后评论
JAVA Q&A
JAVA Q&A

173 篇文章

作家榜 »

  1. JAVA Q&A 173 文章
  2. 江南 1 文章
  3. 伯乐 0 文章
  4. 孤存 0 文章
  5. q21164340 0 文章
  6. 赫敏12 0 文章
  7. 子牙 0 文章
  8. 赫敏 0 文章