微服务架构采用Scale Cube方法设计应用架构，将应用服务按功能拆分成一组相互协作的服务。每个服务负责一组特定、相关的功能。每个服务可以有自己独立的数据库，从而保证与其他服务解耦。
耦合是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象。
解耦：将存在的依赖去掉，比如类A的一个函数需要类B的一个函数返回值，那么A就是依赖B，那么B改动时A很有可能功能受影响，那么不如在中间加另一个类C，使C成为A和B的桥梁，于是A对B的依赖就消失了，B在改动时也不影响A，而想要影响时，改动C就行了，这就是解耦。
我记得是设计模式里什么来着
作者：Niteip
链接：https://www.zhihu.com/question/20821697/answer/27469835
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
微服务优点
1、
通过分解巨大单体式应用为多个服务方法解决了复杂性问题，
每个微服务相对较小
2、每个单体应用不局限于固定的技术栈，
开发者可以自由选择开发技术，提供API服务。
3、
每个微服务独立的开发，部署
4、单一职责功能，
每个服务都很简单，只关注于一个业务功能
5、
易于规模化开发，多个开发团队可以并行开发，每个团队负责一项服务
6、改善故障隔离。一个服务宕机不会影响其他的服务
微服务缺点：
1.开发者需要应对创建分布式系统所产生的额外的复杂因素
l 目前的IDE主要面对的是单体工程程序，无法显示支持分布式应用的开发
l 测试工作更加困难
l 需要采用服务间的通讯机制
l 很难在不采用分布式事务的情况下跨服务实现功能
l 跨服务实现要求功能要求团队之间的紧密协作
2.部署复杂
3.内存占用量更高
内部服务之间的通信方式有两种：
1、基于HTTP协议的同步机制(REST、RPC);
2、基于消息队列的异步消息处理机制(AMQP-based message broker)。
微服务架构的好处
1.单个服务很容易开发、理解和维护。
2.这种架构使得每个服务都可以有专门开发团队来开发。
3.微服务架构模式是每个微服务独立的部署。
4.微服务架构模式使得每个服务独立扩展。
微服务架构的不足
微服务应用是分布式系统，由此会带来固有的复杂性。
服务地址目录，服务健康度，部署困难，服务依赖问题，数据库分区问题。
