一：什么是微服务？
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。 系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。 每个微服务仅关注于完成一件任务并很好地完成该任务。 在所有情况下，每个任务代表着一个小的业务能力。
当然啦，关于微服务还有很多种定义，并没有一个官方的标准，通常在解释微服务的时候，通常会提起一种面向服务的架构——SOA，其核心的原则就是将应用组织成一独立的功能单元，可远程访问并单独进行操作和更新，简单来说，就是每个单元都是一个独立的服务，它可以实现业务的一个方面，并通过接口提供功能，虽然SOA清楚地指出服务应当是独立的进程，但是并未强制使用哪种协议进行交互，对于部署和配置还是相当模糊的，SOA服务可以在同一个机器上使用socket通过IPC（进程间通信）方式进行交互，若要使用内存共享，间接消息队列或远程过程调用（RPC），这是一个非常广泛的定义，只要没用在单个进程中运行所有应用，SOA可以是任何东西
二： 传统的单体结构
举例来说：一个商城，除了要有静态的HTML内容外，还必须要有相关的模块，比如用户模块，订单模块，商品模块，优惠券模块等等，当用户对应用进行操作的时候，会伴随着针对数据库的一些SQL操作，然后再经过渲染返回给HTML的页面，整过过程都相当于在一个应用的整体内进行，较少的对外部服务进行网络请求（比如注册时需要请求第三方短信验证），在经典的LAMP架构中，每个传入的请求都会在数据库生成关联的SQL查询，然后服务器再使用模板引擎生成相应的HTML进行响应。
这种架构有很明显的优缺点，优点就是：1.我们可以很容易的开始一个项目；2.简化了数据的设计和组织；3.部署应用也会相对简单
但他也有很明显的缺点：
1.我们如果想增加一些功能的时候，修改代码可能会影响到原来不相关的功能，对某部分代码的错误修改可能导致整个应用的崩溃
2.扩展应用的解决方案存在的限制：可部署多个实例，但若期中一个特定的功能占用了所有资源，则会影响整个应用
3.随着应用的迭代，代码库的增长，很难保证代码的干净和可控性。
三：微服务架构
这个架构中的每个 组件都使用HTTP协议进行通信，通过REST风格的web接口提供服务，每个微服务都在内部处理自己的数据结构，不需要中心化数据库，使用普遍的数据格式如JSON输入输出数据，任何语言都可生成和使用，最后通过HTTP请求和响应进行传输。总体来说，微服务是一个轻量级的应用，它可以通过良好的契约提供一组有限的功能，它是具有单一责任的组件，可独立开发和部署。
微服务架构的优点：
1.分离开发团队的注重点，每个微服务都可由一个团队独立开发，每一次版本迭代只会在服务的内部进行，不会影响其他的应用，低耦合的开发模式，加快项目的进程。
2.如果在现成的微服务应用中进行跨越式的迭代，比如说更换语言和框架，我们可以把它隔离在一个微服务中，使用独立的数据库，让一小部分用户去试验这个方案，从而不影响整个应用的运行
3.更加灵活的扩展与部署，根据微服务的定义，我们可以将服务部署在不同性能的服务器上面，需要消耗CPU的放在性能优良的服务器上面，只消耗内存的（如Redis这种内存数据库）我们可以部署在CPU稍微较差，而内存较大的服务器上，从而减少了部署的成本