【Spring全家桶系列】 - 关于微服务的一点儿想法

        工作很多年了，一直以来，有很多项目，每次改了代码，编译重启需要花费大量时间，随着项目越来越大，通常编译启动的时间也越来越长，所以有时候在编译启动的时候会跑去看看论坛、帖子之类的，如果是在家里，有时候还会干脆打开一部小说，编译启动时看小说，以前最让人郁闷的一个项目是每天早上到公司打开git，更新、重新编译、启动整个过程完事要一上午，真是让人砸了电脑的心都有，一大堆活要干呢，可你只能干等着，然后下午、晚上赶工。

       多年前，曾经做某个PLM项目的时候，由于系统后来太过庞大，每次更新、编译、重启时间过长，后来项目还曾经专门作过一个功能，在系统中增加一个模块，将新模块的开发脱离原系统，单独完成后，再通过一个功能模块把源码导入系统中，使得新的开发可以脱离原本庞大的系统，以增加开发效率。

        后来听说有了微服务的概念，还特意跑去了解了一下，那时候，我们已经开始使用敏捷开发模式进行开发了，感觉微服务还真是挺适合做敏捷开发的，但是开始我们并没有真正意义上采用微服务，因为现有产品是个庞大的系统，但是，我们也还是逐渐向微服务靠拢，以改善开发效率。

那么到底什么是微服务呢？

       百度百科中说“微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。”

使用微服务能解决我们开发中哪些痛点，总结如下：

1. 大型项目编译、启动速度慢，项目实施效率低下。
2. 上线后的项目，有任何变更或新需求，都需要做大量的测试，以避免影响原有系统。
3. 当前项目实施大多使用敏捷开发，但是项目实施效率低下，使得项目很难真正敏捷起来。
4. 即使分布式部署，也同样每台机器都需要发布所有功能，因为功能在同一个包中。
5. 扩容成本较高，因为要考虑项目整体功能。
6. 项目越大，了解整体项目越难，项目新成员上手越难。
7. 数据库很庞大，并且越来越庞大，有时会引起一系列问题。

但是，同时，微服务也可能会引起新的问题，如下：

1. 微服务要微到什么程度合适？
2. 服务过多，调用复杂性变高，部署复杂性变高，新人上手也会困难。
3. 独立的数据库，造成事务管理困难。
4. 接口改变时，影响较大。
5. 服务过多，导致测试量变大，合作变得更复杂。

……

即使微服务也可能会带来某些问题，但是它仍然解决了我们当前面临的很多问题，所以微服务是如今的大势所趋，如何做好微服务的架构就是重中之重了。

微服务的常见的几种实践：

1. 前端通过接口调用后端，前、后端分别是一个服务。
2. 按照业务分服务，一个子业务一个服务。
3. 一个数据库一个服务
4. 一个接口一个服务

第一种实践，对于业务简单，并且要快速实现的项目来说，不失一个好选择，但是一旦业务复杂，他就会产生和非微服务时一样的问题。

第二种实践，是我们当前比较推荐的应用，但是分解子业务很重要，要做到既不会力度太细，增加其复杂度，又不会太粗，产生如上问题。

第三种实践，对于需要多个数据库来完成的应用，也不失为一个好选择，同样，多数据库的粒度很重要。

第四种不推荐，粒度太细，开发、测试、维护等都是大麻烦。

 

--------推荐视频-------------

玩转Spring Data JPA&Spring Data JDBC

玩转 Spring 全家桶

--------推荐内容-------------

系统上线后雪崩！让我们来学习 Spring Cloud Hystrix 及监控来解决雪崩问题

10 分钟教会你 Spring Boot 集成 Thymeleaf、MyBatis 完成产品的增删改查

【高阶用法】一个实例学会 Spring Cloud 的注册中心 Eureka的使用

Spring Cloud gateway与注册中心Eureka的完美集成