《springcloud学习》二 微服务简介

1.微服务的简介

假设一个场景：网上电影购票系统，涉及的模块有电影模块、订单模块、用户模块。

在没有微服务之前，我们的做法可能是，一个项目，存放所有的模块信息，当前，这种做法也没有问题，可以实现功能，随着我们的业务系统越来越大，代码量，还有用户人群越来越大，这样脓肿的项目，就会存在各种各样的问题，代码维护成本，硬件成本，不好维护等等。这样微服务就应运而生。

我们常说微服务，那什么是微服务？

所谓的微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。微服务设计原则：1、各司其职 2、服务高可用和可扩展性。

      微服务架构是从SOA架构演变而来的，比SOA架构粒度更加精细，让专业的人，做专业的事，目的是为了提高效率，每个服务于服务之间互不影响，每个服务必须独立部署(独立数据库,独立redis)，微服务架构更加体现轻量级，采用restful风格提供api，也就是使用http协议+json格式进行传输，更加轻巧，更加适合于互联网公司进行敏捷开发，快速迭代产品。而SOA架构采用的是SOAP协议,也就是http+xml(占用空间较大)

2.微服务的优点

    2.1易于开发和维护

          一个微服务只关注一个特定业务功能，所以代码逻辑清晰，代码量少，这样就易于维护，而整个应用是有 多个微服务构建而成。例如：上面的购票系统，用户模块就需要辅助用户的业务逻辑，而不用管电影，订单的业务。

    2.2   单个服务启动快

       单个服务，代码量较少，所以启动较快。本人之前就遇到过，启动一个项目服务花了5分钟左右，这还是小型系统，如果是大型系统，启动服务半个小时，也是正常，而一般的外部系统，时时刻刻可能有人在用，所以，一般的部署时间点，都是在凌晨左右，如果中间空缺半个小时左右不能用，我想你的电话，要被客户和公司的人打爆把。

    2.3   单一修改易于部署

     单一应用，只要修改，就得重新部署整个项目，而微服务就不一样，只需要重新发布修改的那个服务就行，一般这个服务，也不止一个，案例：例如游戏的版本1.4  1.5，实际上上线1.5的过程中，1.4版本还是可以正常使用的，这就是因为，该服务不止一份，也就是说，部署不影响系统的客观使用。

  2.4    技术不受限制

            在微服务中，我们可以根据team掌握的技术，合理的选择技术

3.微服务的缺点

       3.1.运维要求较高

             单一应用，只需要打一个包直接部署就行，而微服务，可能是几十个或者上百个服务构成一个应用系统。所以对运维要求较高。 

       3.2   分布式复杂性

         使用微服务构建的是分布式系统，可能存在系统容错，网络延迟，分布式事务等问题

      3.3  接口调整成本高

        微服务之间都是通过接口通讯的，如果需要某一个微服务的接口，可能该服务对应的一系列接口都要更改。

       3.4    重复劳动

        服务之间可能有重复的代码，而这部分代码，没有达到需要独立成一个服务的程度，所以，会有重复代码。

如果你热衷技术，喜欢交流，欢迎加入我们！