为什么到了学习微服务的时候了？

什么是微服务(Microservice)？

微服务从字面上理解就是多个比较小的服务组合起来，那么到底微服务是什么呢?按照字面的理解也并不无道理，微服务是将以往的单体应用按照一定的功能或者其他业务划分成一组组小的服务，服务之间通过轻量级的通信机制相互协作，相互配合，共同为用户提供服务。划分之后的每一个服务都是按照相应的功能进行构建，并且能够被单独部署到生产环境或者测试环境中。

为什么要使用微服务？

单体应用时代，我们的项目工程模块只有一个，所有的功能都集合到一块，这样的工程在运维上是非常方便的，但是如果一旦项目某个小功能出现问题就会导致整个工程出现问题甚至宕机，再者所用功能都集中在一起，项目也显得特别臃肿，开发维护的成本也会因此比较高。因此单体的缺陷也是显而易见的，虽说我们可以通过部署多个单体应用水平扩展，但是一旦出现问题就是整个系统崩溃，这个是生产上不允许出现的情况。在项目上线的时候与功能无关的开发人员也要跟着一起发版，这个是作为开发人员最不想的结果，试问谁不想早点回家陪老婆孩子呢？

如何实现微服务?

至于如何实现微服务？这个问题很大，一千个人就有一千个理解，我就简单的聊聊我对微服务的理解吧。比如说，我们有一个电商系统，那么我们就会有用户、商品、库存、订单、支付等等一系列的业务功能吧。我们一般是按照业务将服务拆分。各个服务之间通过市面上常见的通信机制进行通信(例如: 阿里的Dubbo，Http协议，gRPC等)，针对每个拆分的模块，我们只需要配备少量开发人员就能很好的完成对应的业务，我们可以对每个服务可以进行单独部署，各个模块之间相互依赖，却又相互独立。这给项目的运维带来了难度，但是由于每个应用是独立的，即使一个模块出现问题，也不会影响到其他模块的正常运行，同时每个应用也可以水平扩展提高系统的稳定性，从而实现系统的高可用和高并发。
那么我们要如何去选择对应的技术呢？市面上比较成熟的微服务架构是Spring家族的SpringCloud，提供了一整套可以商用的微服务架构。同时我们也可以通过SpringBoot和Dubbo等通信框架快速搭建微服务架构。至于这些技术怎么实现，可以参考网上已有的教程，技术是不断进步的，在微服务时代我们更加不能放松学习新技术的步伐，稍有不慎我们就会被时代淘汰。好了，鉴于本人的理解能力有限，本文如有不对的地方，敬请批评指正。