它是一种架构模式，提倡将大的单体系统，按业务拆分成一个个较小且独立的服务，服务与服务之前进行相互协作和配合。
针对互联网行业的蓬勃发展，需要支撑的业务越来越多，越来越大，单体程序越来越难以支撑，因此才出现了微服务的这种架构。
1.开发独立：因开发独立就可以使用不同的语言进行开发，这样就更能发挥出各语言擅长的方面。
2.低耦合 ：服务与服务间采用轻量级的通信机制相沟通（Http，tcp/id），当某一服务出现问题，可以通过“降级熔断”等手段来保证系统不雪崩。
3.独立部署：这个就厉害了，独立部署带给我们的就是快速的迭代，完全与现在的敏捷开发相符。
4.横向扩展：这就是对于某一个服务的压力大的时候，我们就可以针对这一个服务进行集群扩展，而不像原单体系统那样，需要整个系统作扩展。
1.因架构使各服务（系统）的颗粒度更小了，整体来说对开发和维护的难度就增加。（当然现在以云的方式部署，因此能屏蔽一些问题）
2.因服务与服务之前的通信机制是网络的方式，因此对于单体的进程内通信就显得运行效率降下来了。
1.单一职责：每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑
2.服务自治：每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
3.轻量级通信：首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
4.接口明确：由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
1.微服务拆分原则:领域模型、限定上下文、组织架构、康威定律
1.通信技术方案: RPC vs REST vs 异步消息
微服务是近期兴起的一种架构模式，因此再使用时，我们就会遇到不同的坑，比如需要依赖的中间件更新速度比较快，因此会造成每个版本在使用上的不同。因此在使用时请注意尽量选择一些大公司已经使用的技术。
每一天都是崭新的，我们的目标有多远，我们就能走多远，坚持！！