大家好，我是哪吒。

一、前言

微服务已经是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、拆分原则

1. 体量较轻：每个微服务的规模应该适中，避免过于复杂或过于庞大。
2. 支持跨平台、跨语言通信协议：微服务应该具备跨平台、跨语言的通信能力，以便能够与其他服务进行有效的交互和集成。
3. 操作性强、易于测试：微服务应该具备易于操作和测试的特性，以便能够快速、准确地实现业务需求。
4. 明确接口要实现的内容：在拆分微服务时，需要明确每个服务接口要实现的功能和业务逻辑，避免出现接口依赖的情况。
5. 持续演进原则：在拆分微服务时，应该考虑到服务的可扩展性和可靠性，以便能够适应业务需求的变化和容错处理。

2、拆分时机和拆分方法

（1）根据负责一个微服务原则进行拆分

在拆分微服务时，可以根据业务领域和实际需求来决定拆分的时机。通常情况下，如果团队规模较小，可以将多个业务功能整合成一个微服务；如果团队规模较大，则可以将一个业务功能拆分成多个微服务。

（2）基于可扩展性拆分

在拆分微服务时，可以考虑将系统中业务模块按照稳定性进行排序，将已经成熟且稳定性高的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。这样可以提升项目的迭代速度，避免对已有成熟功能产生影响。

（3）基于可靠性拆分

在拆分微服务时，可以考虑将系统中业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的服务拆分出来。这样可以保障核心服务的可用性。

3、拆分实践

（1）持续演进

在微服务的拆分过程中，应该遵循持续演进的原则，逐步拆分细化，而不是一次性拆分成无数个微服务。这样可以避免微服务数量瞬间爆炸性增长，降低开发、测试、运维等环节的难度。

（2）非业务因素考虑

在微服务的拆分过程中，除了要遵循拆分原则和考虑业务因素外，还需要关注非业务因素，如需求变更的频率、高性能、安全性、团队规模以及技术异构等因素。这些因素对于最终落地也会起到决定性的作用。

（3）最佳实践

根据实际情况和实践经验，可以采用一些最佳实践来指导微服务的拆分。例如，可以根据团队规模来决定服务的拆分粒度；根据业务领域和实际需求来确定服务的拆分时机；根据稳定性、优先级等因素来确定服务的拆分方法等。

微服务的拆分需要结合实际情况和实践经验来进行综合考虑和分析。只有在明确了业务需求、团队规模、技术栈等因素后，才能制定出合适的拆分方案，实现微服务的有效拆分和管理。

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

1、确保相关业务和利益相关者的支持

在决定是否使用微服务架构之前，需要与所有利益相关者进行沟通和合作，确保他们理解并支持这个决策。同时，需要评估组织的技术专业知识水平，并准备相应的资源来支持微服务架构的实施和运维。

2、确定微服务的拆分粒度

微服务的拆分应该根据业务领域和实际需求来确定，同时需要考虑服务的稳定性、优先级、可靠性等因素。拆分粒度应该适当，避免过度拆分或拆分不足。

3、遵循微服务架构的原则

微服务架构需要遵循一系列原则，例如单一职责原则、接口隔离原则、服务自治原则等。这些原则可以帮助设计出更好的微服务架构，并减少潜在的问题。

4、确保接口的稳定性

微服务之间的通信依赖于接口，因此需要确保接口的稳定性。接口需要遵循一定的规范，例如RESTful API、RPC等，以确保不同微服务之间的通信可靠性和性能。

5、关注数据一致性

在微服务架构中，不同的服务可能由不同的团队开发和维护，因此需要关注数据的一致性。需要设计适当的数据存储方案，并确保不同服务之间的数据一致性和完整性。

6、考虑安全性

微服务架构中的安全性是一个重要的问题。需要确保每个微服务的安全性，包括身份认证、访问控制、数据加密等方面。同时，需要考虑到跨域请求的安全性，以避免潜在的安全漏洞。

7、做好监控和日志记录

微服务架构中的每个服务都需要进行监控和日志记录。需要确保每个服务都具备适当的监控和日志记录机制，以便及时发现和解决问题。

8、做好容错处理

微服务架构中的每个服务都可能出现故障或异常情况。因此，需要设计适当的容错处理机制，以避免故障或异常情况对整个系统造成严重影响。

使用微服务需要注意多个方面的问题，包括业务支持、拆分粒度、原则遵循、接口稳定性、数据一致性、安全性、监控和日志记录以及容错处理等。只有在全面考虑并处理好这些问题后，才能实现微服务的成功实施和运维。

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

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

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