微服务介绍

一、微服务介绍

        服务，一定要区别于系统，服务是一个或者一组相对较小且独立的功能单元，是用户可以感知的最小功能集。

二、微服务的由来

        微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

三、为什么需要微服务

        1、微服务与单体架构的区别

        单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

        单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

        单体架构所有的模块开发所使用的技术都一样，微服务每个模块都可以使用不同的开发技术，开发模式更加灵活。

        2、微服务与SOA区别

        微服务从本质上讲还是SOA架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有java编写的服务，也可以有Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以，微服务本身与具体的技术实现无关，扩展性强。

四、微服务本质

        1、微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立地部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等。

        2、微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

        3、inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

四、什么样的项目适合微服务

        小：微服务体积小，pizza 团队。

        独：能够独立的部署和运行。

        轻：使用轻量级的通信机制和架构。

        松：服务之间是松耦合的。

五、微服务折分与设计

        拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。

六、微服务拆分与设计

        单一职责原则

        意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。

        服务自治原则

        意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。

        轻量级通信原则

        首先是通信的语言非常的轻盈，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。

        接口明确原则

        由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。

七、微服务开发框架

        目前微服务的开发框架，最常用的有以下四个：

        Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）

        Dubbo：http：//dubbo.io

        Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）

        Consul、etcd&etc.（微服务的模块）