认识达内从这里开始

认真做教育专心促就业

武汉达内java培训班服务化拆分的前置条件

发布：武汉IT培训
来源：互联网
时间：2023-09-19 10:14

我们在前几期的文章中给大家简单介绍了程序员在学习微服务架构开发技术的时候需要掌握的一些基础知识点等内容，而本文我们就再来学习一下服务化拆分的前置条件。

武汉达内java培训班服务化拆分的前置条件

一般情况下，业务系统引入新技术就必然会带来架构的复杂度提升，在具体决策前，你先要认识到新架构会带来哪些新的问题，这些问题你和你的团队是否能够解决?如何解决?是自己投入人力建设，还是采用业界开源方案?

下面几个问题，是从单体应用迁移到微服务架构时必将面临也必须解决的。

服务如何定义。对于单体应用来说，不同功能模块之前相互交互时，通常是以类库的方式来提供各个模块的功能。对于微服务来说，每个服务都运行在各自的进程之中，应该以何种形式向外界传达自己的信息呢?答案就是接口，无论采用哪种通讯协议，是HTTP还是RPC，服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。

服务如何发布和订阅。单体应用由于部署在同一个WAR包里，接口之间的调用属于进程内的调用。而拆分为微服务独立部署后，服务提供者该如何对外暴露自己的地址，服务调用者该如何查询所需要调用的服务的地址呢?这个时候你就需要一个类似登记处的地方，能够记录每个服务提供者的地址以供服务调用者查询，在微服务架构里，这个地方就是注册中心。

服务如何监控。通常对于一个服务，我们关心的是QPS(调用量)、AvgTime(平均耗时)以及P999(99.9%的请求性能在多少毫秒以内)这些指标。这时候你就需要一种通用的监控方案，能够覆盖业务埋点、数据收集、数据处理，后到数据展示的全链路功能。

服务如何治理。可以想象，拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。比如一个服务的性能有问题时，依赖的服务都势必会受到影响。可以设定一个调用性能阈值，如果一段时间内一直超过这个值，那么依赖服务的调用可以直接返回，这就是熔断，也是服务治理常用的手段之一。

故障如何定位。在单体应用拆分为微服务之后，一次用户调用可能依赖多个服务，每个服务又部署在不同的节点上，如果用户调用出现问题，你需要有一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从而进行故障定位。

针对上述问题，你必须有可行的解决方案之后，才能进一步进行服务化拆分。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。

< 上一篇：武汉达内java培训机构微服务拆分应用实践分享

下一篇：软件开发程序员需要掌握哪些镜像存储结构 >