【网站架构】SpringCloud不等于微服务，总结微服务的4个核心点

 

本期我们来聊一下微服务，微服务这个名词大家肯定是不陌生的。

简单地说，微服务就是把系统拆成独立的多个服务，而非单体服务。它的易维护、易扩展、低耦合等优点也是被认为吊打传统的单体服务。

但我们想说的是，很多项目虽然强调自己是微服务，但其实并不是。更直接地说，并不是使用了SpringCloud就是微服务。

我们参与过几个项目的质量评估，它们都使用了SpringCloud。虽然把服务分成了几十个 ，但是数据库用的却是同一个，所有的数据表都集中在一个数据库当中。

这种做法其实仍然是单体服务，因为最终的压力会积压到单体数据库当中，后端服务器即使扩展10台机器，性能仍然不会有所改善。

另外，由于数据等服务仍然是单体的，所以在改动数据表时，根本不知道会影响什么接口。

而且由于后端代码分散在多个工程之中，维护性反而更低。

这里想说的是，不要把手段当成目的，任何框架或技术工具都只是解决问题的手段。

其实，微服务只是一种设计概念，跟我们是否使用SpringCloud、配置中心（Nacos等）、注册中心（SpringCloud GateWay等）并没有直接关系。

而且很多时候，不分青红皂白地使用这些技术工具，反而会让总体结构十分臃肿，实际运维成本反而更高。

而SpringCloud说白了也只是一堆工具集，而非传统意义的框架。后端程序的框架仍然可以是SpringBoot，或者是其他开发语言的框架。

所以，我们在往期《后端架构需要解决的问题》中，并没有强调微服务，而只是强调了应用拆分。 

当然，应用拆分更偏向于分布式的概念，但是，实际项目当中，管它是什么概念 ，只要能让系统维护性、扩展性更高就好了。

所以，想做好微服务，关键点并不是如何使SpringCloud ，而是需要考虑好以下几点：

1. 应用拆分

2. 共享状态

3. 应用间协调

4. 服务器扩展 

应用拆分

在实际项目当中，我们更偏向按照业务架构划分应用 ，当然，一些在数据上高度关联的应用需要合并 ，如资金系统与优惠券系统。

业务架构设计可参考我们的往期《业务架构设计》的视频，应用划分不能仅对后端程序划分 应该包含数据库、非关系型数据库、前端页面等。

当然，分离数据库并不意味着需要多个服务器部署实例 ，在运行压力不高时，可以在一个实例中创建多个数据库，当运行压力上来时，再分离出多个实例。

原则上，数据部分的拆分只要做到分离出多个实例时不需要改动代码即可。

垂直划分的好处除了能在服务器扩展时更方便，还有一个好处，系统开发时可以多个应用同步开发 ，而非十几个人挤在一个工程中，然后出现各种代码冲突等问题 。

状态共享

应用拆分后，会存在状态共享的问题，简单地说，就是用户通过应用A登录，应用B并不知道其登录状态或权限信息。

很多项目的做法是引入单点登录系统，通过OAuth2.0等方法实现状态共享，当然Spring security也能解决这样的问题。如果熟悉这些方法的话，继续使用即可。

但这些方法未免有些臃肿，比较适合一个大型系统中各个系统的状态共享。

而一个系统中的各应用其实通过共享Session就能解决这个问题 。SpringBoot的话，使用redis就可实现多应用共享session，也可以通过jwt（Json web token）等方式实现状态共享。

应用协调

应用协调是微服务的一大难题，如果熟悉Dubbo等方式的话，继续使用就好了。

但是按照我们往期《数据库事务与分布式事务》中的结论，只要应用分离得合理 ，应用间的业务关联其实没有想象中高 ，应用间的协调可以通过前端网页整合API 或者通过统一的流程中心整合应用间的调用。

这样可以让应用间的关系更加一目了然，有兴趣的小伙伴可以翻看往期《数据库事务与分布式事务》的分布式事务部分。

 

至于前端部分，由于分离了前端工程，我们是推荐使用iframe嵌入的。

虽然很多人都对iframe有所排斥（包括当初的我们）， 但实际应用下来确实比较好用 ，有兴趣的小伙伴可以翻看往期《前端单页应用》的内容。

服务器扩展 

微服务的服务器扩展一般在开发阶段是不用考虑的，但是，开发时需要记住运行环境并不是单机的，这样能避免很多不必要的BUG，如多个服务实例触发多次相同的定时服务等。

关于服务器扩展的问题将会在整体架构部分的动态弹缩再详细讨论， 因为服务器扩展是一个复杂问题，尤其是数据部分的服务器扩展。

所以并不是使用了网关与注册中心就可以了（如Spring GateWay等）。 服务器扩展一般是以一整个应用为单位的，包括其后端程序、数据服务等部分。

总结 

以上就是微服务的相关内容，具体的实现方法我们将会在后续的点单登录系统介绍时详细讨论。

微服务除了以上关键问题 ，还有日志收集、日志链路追踪等细节问题，这里不做过多讨论。

我们认为微服务想要实现的未来，是近乎热插拔的效果（当然实际很难完全热插拔，实际也不会来回插拔….），也就是加入了商城应用（需要一些配置），网站系统即拥有商城的业务功能，就好比一个智能手机，安装了购物APP就能拥有购物功能一样。

这也是我们的创业方向，重复了太多次的系统构造的0到1过程 ，停止重构就是我们的愿景。

我们预计8月左右会陆续推出我们的应用产品， 当然，我们会分享我们的设计思路与开源部分产品 。

敬请期待