1 微服务思想
服务运行在自己的进程中，是一个小而独立的服务单元
使用轻量级通信机制，通常是http api
能够自动化独立部署
最低限度的集中式管理
2 单体架构的弊端
一个单体架构，就是一个架构中包含所有功能，当业务规模小的时候运行ok，但业务变庞大后，就会出现很多麻烦，
模块不清晰，彼此之间界限模糊，整个架构复杂
技术负债高，新接手的人员不容易明白各种细节，各种坑。
架构扩展难，由于单个服务不是独立的，需要整个单体架构联动调整，高耦合带来扩展难。
3 微服务优势
服务独立性：假设在后端体系上，分为路由转发层-主体业务层-后端调用模块层-数据缓存层-数据储存层。每个后端模块都相当于一个独立的项目，如果要加一个模块，只要部署一个进程就行。
层次清晰：假设还是上面的体系，不同的层次在不同的服务器上。
弹性调整：主体业务层是cpu/mem密集型，数据缓存层是mem密集型，数据储存层是磁盘io密集型，就可以针对性硬件调整。
松耦合：一大堆微服务组成整个分布式架构，微服务之间是彼此调用的关系，微服务可以独立部署，下线，升级等，对其他微服务影响降到最低。
轻量级启停：由于彼此之间的相对独立性，可以对一个进程进行启停操作，不用重启整个架构。
轻量级通信：微服务都是进程的形式，然后监听tcp端口，彼此之间通过套接字连接。
4 设计原则
单一职责：一个微服务的粒度应该是一个子功能，处理一种业务功能，不考虑其他的业务功能。
服务自治：一个微服务1-2个人就可以完成从开发，接入，测试，上线，维护整个流程。是一个独立的项目。
接口统一：微服务之间都是通过接口调用来联动的，所以要有明确的接口规范。
5 服务发现
在微服务架构中，每个服务必然会有多个进程，作为拷贝在运行，甚至运行在不同的服务器上，提供负载均衡功能和防止单点故障。微服务之间需要有一套可靠的发现机制，某个微服务的其中一个进程up/down时，可以被调用者感知。ZK提供了这样的功能，每个微服务启动时，会向ZK注册临时节点，当ZK在超时时间外无法连同微服务，就删除临时节点。调用者会根据ZK信息寻址到被调用者，如果发现被调用者在ZK中没有节点，则换一个。
6 分布式的不可靠性
启停和发现都要经过ZK，具有不可靠性。