先来看看维基百科和百度百科给出的定义：维基百科：2014年，MartinFowler和JamesLewis共同提出了微服务的概念，并定义了微服务。服务是由单个应用程序组成的小型服务，它有自己的调度和轻量级处理。服务按业务功能设计，全自动部署，使用HTTPAPI与其他服务通信。同时，服务会使用最小规模的集中管理（如Docker）能力，服务可以用不同的编程语言、数据库等组件来实现。百度百科：所谓微服务就是SOA架构下的最终产物。这种架构的设计目标是将业务进行肢解，让服务独立运行。微服务设计原则：1.各司其职。2、服务高可用和可扩展性的概念比较抽象。下面我将从一个单体应用入手，解释为什么会有微服务，什么是微服务。1、单体应用早期互联网公司的应用技术栈大致分为两派：LAMP（Linux+Apache+MySQL+PHP）和MVC（Spring+iBatis/Hibernate+Tomcat）。两者都是针对单体应用架构设计的，优点是学习成本低，开发速度快，测试部署运维方便。以MVC架构为例，业务通常是通过部署一个War包到Tomcat中，然后启动Tomcat，监听某个端口对外提供服务。早期业务规模小，开发团队少，采用单体应用架构，团队开发运维成本可控。但是，随着业务规模的不断扩大，团队开发人员的不断扩大，单体应用架构会开始出现问题，可能会出现以下几个方面的问题。部署效率低：当单体应用的代码越来越多，依赖的资源越来越多时，编译、打包、部署、测试一次应用甚至可能需要10多分钟。团队合作开发成本高：当团队扩大时，多人修改代码，然后一起打包部署，只要在测试阶段某个功能出现问题，就得重新编译打包部署，然后再次预览和测试。参与其中效率低下且开发成本极高。系统高可用差：由于所有功能开发最终部署到同一个War包中，运行在同一个Tomcat进程中，一旦某个功能涉及的代码或资源出现问题，将影响整个WAR中的部署封装函数。线上发布较慢：一旦代码膨胀，服务启动时间会变长。因此，迫切需要一种能够将应用的不同模块解耦，降低开发部署成本的方法。为了解决以上问题，应运而生了面向服务的思想。2.ServicingServicing是将传统单机应用中通过JAR包依赖产生的本地方法调用，转化为通过RPC接口产生的远程方法调用。在编写业务代码时，将通用的业务逻辑抽象出来，独立成一个专门的模块，对于代码复用和业务理解都有很大的好处。以微博系统为例，微博不仅包括内容模块，还包括消息模块和用户模块。消息模块依赖于内容模块，消息模块和内容模块都依赖于用户模块。当这三个模块的代码耦合在一起时，应用启动时，需要加载各个模块的代码，同时连接相应的资源。一旦任何一个模块的代码出现bug，或者依赖的资源出现问题，都会影响到整个单体应用。为此，首先可以将用户模块从单体应用中分离出来，独立部署为一个服务，以RPC接口的形式对外提供。当微博和消息模块调用用户界面时，进程内调用变成了远程RPC调用。这样，用户模块可以独立开发、测试、上线和维护，可以交给专门的团队，无需与主模块耦合。此外，消息模块也可以拆分成一个独立的模块，由专门的团队进行开发和维护。可见，通过服务化可以解决单体应用扩展、团队开发耦合度高、协作效率低等问题。3、微服务从2014年开始，随着容器化技术的成熟和DevOps文化的兴起，服务的思想进一步演变为微服务。微服务和服务化的区别可以概括为以下四点：服务拆分的粒度更细：微服务可以说是更细的维度面向服务，小到一个子模块，只要资源那个模块依赖的和其他模块一致没关系，那么可以拆分成一个微服务。服务独立部署：各个微服务严格遵循独立打包部署，互不影响的原则。比如一台物理机上可以部署多个Docker实例，每个Docker实例可以部署一个微服务的代码。服务独立维护：每个微服务都可以由一个小团队甚至个人进行开发、测试、发布和维护，并负责整个生命周期。对服务治理能力要求高：拆分成微服务后，服务数量增加，需要统一的服务治理平台来管理各个服务。以微博系统为例，可以进一步划分内容模块的功能。例如，内容模块包括提要模块、评论模块和个人页面模块。通过微服务，将这三个模块变成三个独立的服务，每个服务依赖自己的资源，独立部署在不同的服务池中，可以由不同的开发者维护。当评论业务需求发生变化时，只需要修改与评论业务相关的代码，独立发布上线；而提要服务和个人页面服务则不需要更改，也不会受到发布可能带来的更改的影响。可见，微服务为服务的发布和部署，以及服务的保障带来了诸多好处。4.单体应用和微服务应用的区别单体应用微服务应用进程号把所有的功能放到同一个进程中把功能的每个元素放到单独的多个服务进程中扩展的方式是通过复制整个应用扩展到多台服务器是通过在不同的服务器上分发不同的服务并按需复制服务。快速响应变化。部分更新需要重新部署整个应用程序。部署和升级是独立的，极大地帮助提高了系统变更的敏捷性。团队结构是垂直的。每个团队负责特定区域。团队结构扁平化，每个团队服务一项服务。整个业务能力的可用性。一项服务的不稳定可能会导致整个应用程序出现问题。一项服务不稳定，影响范围相对较小。创新很难引入新的技术和框架。所有功能都使用相同的框架。每个微服务可以使用不同的语言和框架。方便引进新技术。5.总结从单体应用演进从基于服务的拆分部署，随着移动互联网规模的不断扩大，敏捷开发、持续交付、DevOps理论的发展与实践，以及容器技术的成熟，微服务建筑已经流行起来。微服务的核心在于服务治理。微服务架构就是将复杂臃肿的单体应用拆分成细粒度的服务。每个拆分服务独立打包部署，交由一个小团队进行开发和运维，从而大大提高了应用交付的效率。
