大家好，我是哪吒。

一、前言

微服务已经是Java开发的必备技能，甲方不管项目大小，都想上微服务，感觉上了就高大上了，牛逼了。

微服务确实给我们带来了一定的便利性，但是也带来了麻烦，比如学习成本高，存在很多不可预见的问题。

我是做互联网项目的，刚开始的时候，用的是springboot+vue的单体架构，虽然也用了很多中间件，云服务器，数据库集群等，但终究还是单体服务，存在着一定的限制，随着业务架构的不断扩大，每次功能发布上线，都需要每个开发负责人对代码进行打包，再进行最后的代码合并，这时候，就会遇到各种各样的问题，代码忘记提交了，提交了忘记打包了，提交的时候忘记更新了，代码冲突了，jar包版本不统一、jar包版本冲突等各式各样的问题。

有一次项目部署测试，后台通过SVN提交记录进行增量打包，然后通过xshell进行Linux服务器程序更新，再重启。一套下来，差不多需要半个多小时的时间，而且因为缺少class文件的原因，反反复复更新了三次，我都要崩溃了~

你是否也遇到过同样的问题？

如果也是这样，是时候将架构升级为微服务了。分功能开发，每个小团队负责一个功能，然后部署为微服务，引入Docker容器技术。

系统架构经历了单体服务 -> 微服务架构 -> 容器化应用-> DevOps的发展历程。

微服务的概念是在2014年由Martin Fowler和James Lewis共同提出的，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程和轻量化处理，按照业务功能分别处理，以全自动的方式部署，与其它服务使用HTTP API通讯。同时，服务会使用最小规模的集中管理（比如Docker），每个服务可以使用自己的语言和数据库。

二、单体服务的弊端

1. 部署成本高，效率低下
2. 团队协作开发成本高，两个人同时编写一个类，谁先提交谁舒服，哈哈
3. 系统高可用性差，因为所有功能最后都部署在一个war包里，运行在同一个Tomcat进程中，一旦某一功能出现问题，就会导致整个系统的崩盘，虽然还有其它机器提供服务，但因为一个小问题，就挂了一个机器，这不蛋疼吗？
4. 线上发布变慢，一般单体服务都是通过人工去更新代码，然后再重启，一个服务部署了16个机器，就要手动替换16次，而且可能还会有更多的服务。

想要解决以上问题，微服务应运而生。

三、微服务化

微服务化，在我看来就是将 传统的单机应用中通过jar包依赖产生的本地调用 改造成 通过RPC远程接口调用。对于一些通用的业务逻辑，想办法将其抽象并独立成专门的模块，因此对代码复用、分小组开发、单业务理解都大有裨益。

在最近的项目经历里，我深有体会，比如将一个项目分为公共模块、注册中心、网关模块、管理模块、某个单业务模块等。一个人一个模块，自己开发自己的，互不干预，每个模块独立开发，独立部署、独立测试、独立上线、独立运维，与其它模块基本上零联系。

可见，通过微服务化，可以解决应用单体膨胀，团队开发耦合度高、测试难、部署难的问题。

四、服务如何拆分？

比较常见的是根据不同的业务去拆分，一条业务线一个服务，这种拆分方式被称为纵向拆分，是从业务维度进行拆分。标准是按照业务关联程度来绝对，关联比较密切的业务适合拆分成一个微服务，而功能相对独立的业务适合拆分成一个微服务。

还有一种拆分方式是横向拆分，核心思想是拆分出通用共用的服务，就像单体服务中的工具类，供每个服务去调用。

五、使用微服务的注意事项

1、服务如何定义

对于微服务而言，每个服务都运行在各自的进程中，通过定义接口的形式去定义服务，约定好接口名、接口参数、接口返回值。

2、服务如何发布和订阅

单体应用时，将整个项目都部署在一个war包中，接口之间的调用属于进程内的方法调用。

在微服务架构中，可以将每个接口注册到注册中心，并由注册中心再对外提供服务。

3、服务如何监控

对于一个接口，我们最关心的是QPS（调用量）、AvgTime（平均耗时）、吞吐量等指标。这时候，需要一个通用的监控方案，能够覆盖所有业务接口，进行数据收集、数据处理、最后到数据展示的全链路功能。

4、服务如何治理

当某个服务有性能问题的时候，依赖的服务也会受到影响，可以根据实际情况设置一个阈值，超过这个时间就进行服务熔断，直接返回。

5、故障如何定位

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

🏆哪吒多年工作总结：Java学习路线总结，搬砖工逆袭Java架构师。

华为OD机试 2023B卷题库疯狂收录中，刷题点这里

刷的越多，抽中的概率越大，每一题都有详细的答题思路、详细的代码注释、样例测试，发现新题目，随时更新，全天CSDN在线答疑。