前言

最近接触到了 Spring Cloud ，虽然还没有正式的在生产环境当中使用，但是那种尽量将一个大的整体才分成小的模块的这种想法，让我不明觉历。恰好最近实训当中写的项目是基于 Spring Boot 的，于是打算魔改成一个简单的 Spring Cloud 项目。也天生 Spring Boot 就和 Spring Cloud 无痛融合。

关于微服务

简单的理解和学习了Spring Cloud 和所谓微服务的概念之后，有了以下一些对微服务的个人理解

1，微服务以服务为核心

从前我们可能也都习惯在项目当中划分模块这个样子，所以一开始接触微服务的时候，我误以为所谓的微服务、多个服务，就不过是将项目里面的各个模块做成一个服务这样。但后面发现实际上，服务和系统模块，并不一定等同。

例如我的实训项目当中，起初的模块划分不过只有微信用户模块和管理员模块而已，如果按照这样划分的话，划分出两个 service （service-wechat 和 service-admin ） 就可以，但是实际上，微信用户模块当中，还有更加细粒度的划分，例如专门负责微信用户登录、鉴权的，专门负责微信用户订单处理的，专门负责微信用户之间的留言的。

而这些才是所谓的服务

微服务抽象的应该是这些处理具体事务，一个个的功能，将这些当个功能抽取成一个模块才对。

“一个模块只做一件事，并且只做好一件事情”

2，微服务的优缺点

我个人觉得微服务最大的优点，是它所谓的“做好一件事”这样的思想。我们把整个系统划分成很多的“一件事”，而对于系统性能的调配，也能够更加的细粒度，对应到各个“一件事”当中。例如我可以为订单功能划分更多的计算性能（在更多的服务器上面部署订单服务并启用负载均衡），而用户授权认证的话只需要使用之前的那一台服务器就可以满足新增的请求压力了。

另外就是更加方便了多人之间的开发，各个小组在约定好程序之间沟通逻辑之后，只需要负责好，测试好自己的那一块就好了。

而最大缺点则是，太过碎片化了。由于原有的单体系统变成了一小块一小块的，各个小块之前，比起之前要耗费多余的资源来负责各个服务之前的沟通和交流。而且对一些需要锁的服务也提高处理难度。

基本的想法

• 将我们的 Spring Boot 项目进行拆分
• 将拆分的各个模块变成 Spring Cloud 的一个服务
• 创建 Spring Cloud 里面的服务器发现，来组合和管理各个服务

……