首先了解技术架构的演变过程，单体应用架构-->垂直应用架构-->分布式架构-->SOA-->微服务
SOA与微服务
SOA:面向服务架构
优点：
抽取公共的功能为服务，提高开发效率，对不同的服务进行集群化部署，解决系统压力。基于ESB/DUBBO减少系统耦合
缺点：
抽取服务的粒度大，服务提供方与服务调用方接口耦合度较高。
那什么是微服务呢？
简而言之，微服务架构风格这种开发方式，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量级的机制来互相通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
从技术维度来理解：
微服务的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念,能够自行单独启动或销毁，拥有自己独立的数据库
微服务与微服务架构
微服务
强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的看，可以看做IDEA中的一个个微服务工程，或者moudel.
微服务架构
一种新的架构形式，由Martin Fowler于2014年提出。它提倡将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程内，服务之间互相协调，互相配置，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中，另外应尽量避免统一的，集中的服务管理机制，对于具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储；
微服务的特点：
1.每个微服务可独立运行在自己的进程里
2.一系列独立运行的微服务共同构建起了整个系统
3.每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等。
4.微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
微服务的优点：
每个服务足够内聚，足够小，能聚焦一个指定业务功能。
开发简单，开发效率提高，一个服务专一的只干一件事， 易于开发和维护。
微服务是松耦合的，是具有功能意义的服务，无论是在开发阶段或部署阶段都是独立运行的，启动较快。
技术栈不受限，微服务能使用不同的语言开发。
局部修改容易部署
易于和第三方继=集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如bamboo，Hudson
微服务只是业务逻辑的代码，不会和html，css或其他界面混合
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库
微服务带来的挑战
运维要求较高(多服务运维难度，随着服务的增加，运维的压力也在增大)
分布式的复杂性
接口调整成本高
系统部署依赖
系统集成测试
性能监控
微服务设计原则
单一职责原则
服务自治原则
轻量级通信原则
接口明确原则
微服务技术栈
| 微服务条目 | 落地技术 |
| 服务开发 | SpringBoot，Spring,SpringMvc |
| 服务配置与管理 | Netflix公司的Archaius ,阿里的Diamond等 |
| 服务注册与发现 | Eureka, Consul , Zookeeper等 |
| 服务调用 | Rest, RPC , gRPC |
| 服务熔断器 | Hystrix, Envoy等 |
| 负载均衡 | Ribbon ， Nginx等 |
| 服务接口调用(客户端调用服务的简化工具) | Feign等 |
| 消息队列 | Kafka, RabbitMQ, ActiveMQ等 |
| 服务配置中心管理 | SpringCloudConfig, Chef等 |
| 服务路由(API网关) | Zuul等 |
| 服务监控 | Zabbit, Nagios, Metrics, Specatator等 |
| 全链路追踪 | Zipkin, Brave, Dapper等 |
| 服务部署 | Docker,OpenStack,Kubernetes等 |
| 数据流操作开发包 | SpringCloud Stream(封装与redis，rabbit,Kafka等发送接收消息) |
| 事件消息总线 | SpringCloud Bus |
如有不同意见，欢迎留言指正。大家一起进步呦！！！
