微服务的概念
对于目前而言，对为服务业界并无一个统一的标准的定义
但一般而言，为服务架构是一种架构模式或者说是一种架构风格，它提倡单一应用程序划分红一组小的微服务 ，每一个服务运行在其独立的本身的进程中，为服务之间互相协调，互相配合，为用户提供最终价值。服务之间采用轻量级的通讯机制互相沟通（一般是基于HTTP协议的RESTful API）。每一个为服务都围绕着具体业务进行构建并能独立的部署到生产环境、类生环境等。另外，为了不同一的、集中的服务管理机制，对具体一个为服务而言，根据业务上下文选择合适的语言、工具对其进行构建，能够有一个非轻量级的集中式管理来协调这些服务，可使用不一样语言来编写这些服务，可使用不一样的数据进储存。
微服务的理解
微服务化的核心就是将传统的一站式应用，根据业务拆分红一个一个的服务，完全去耦合每个微服务提供单个业务功能的服务，一个服务作一件事，从技术角度来看就是一种小而独立的处理过程，相似进程概念，能自行单独启动或销毁，拥有本身独立的数据库。
微服务能够理解为IDEA或eclipse工具里面用maven开发的一个个独立的小moudle，它具体使用spring boot开发的一个小模块，专业的事情交给专业的模块来作，一个模块就是一个小的微服务
强调的是一个个的个体，每一个个体完成一个具体的任务或功能
能够把这个微服务的项目看成成一个医院，而医院的一个一个的但是就是一个一个的微服务
微服务架构
微服务构架的概念
微服务架构是一种架构模式，他提倡单一拥应程序划分红一组小的服务，服务之间相互协调，相互配合，为用户提供最终价值。每一个微服务运行在其独立的进程中，服务与服务之间采用轻量级的通讯机制相互协调（一般是基于HTTP协议的RESTful API）。每一个微服务都围绕着具体业务进行构建，而且可以被独立的部署到生产环境、类生环境等。另外，应尽可能避免统一的、集中的管理机制，对具体的一个微服务而言，应根据上下文选择合适的语言、工具进行构建。
微服务的优缺点
优势：
每一个微服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求
开发简单，开发效率高，一个微服务就专注的干一件事
微服务可以被小团队单独开发，这个小团队是2到5人的开发人员组成
微服务是松耦的，是由功能意义的服务，不管是在开发阶段或部署阶段都是独立的
微服务能使用不一样开发语言
易于和第三方集成，微服务容许容易且灵活的方式集成自动部署，经过持续集成工具，如JenKins，Hudson，bamboo
微服务易于被一个开发人员理解，修改合维护，这样小团队能更关注本身的工做成果。无需经过配合才能体现价值
微服务容许你利用融合最新技术
微服务只是业务逻辑代码，不会和HTML、CSS或其余界面组件混合
每一个微服务应有本身的存储能力，能够有本身的数据库，也能够有统一的数据库
缺点：
开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增长，运维的压力也在增大
多个系统的部署依赖
服务之间的通讯成本
数据的一致性
系统集成的测试
性能的监控web