1.每个微服务都是自 包含（self-contained），各自维护自己的数据存储，这样就必须在设计数据库的时候考虑服务的相对独立性。
2.更容易差异化部署，比如有些服务对硬件要求低，有些就很高，可以差异化购买或搭建云服务。
3.符合DevOps 文化，什么是DevOps：https://www.cnblogs.com/liufei1983/p/7152013.html
4.API网关，提供了统一的微服务单入口，提供负载均衡、缓存、访问控制、API 计量和监控。
5.微服务架构中的进程间通信，微服务之间的相互通信。
6.微服务架构中的服务发现，当服务运行在一个动态环境中，想要找到他们并不是一件简单的事情，我的理解是因为环境是动态的，所以用注册发现机制可以实现相对稳定的访问机制。不应该因为微服务换了IP或者是主机而改变其他服务调用该微服务的方式。
7.微服务事件驱动数据管理：由于每个微服务维护一个数据存储，导致应用变得复杂。所以引入了这个概念。
8.选择微服务部署策略
9.微服务架构模式明显影响到了应用程序与数据库之间的关系，与其他共享单个数据库 模式（schema）服务有所不同，其每一个服务都有自己的数据库模式
微服务最佳实践：
1.一个微服务尽可能的解决一个问题。
微服务的缺点：
1.分布式系统肯定比单系统复杂。
2.分区数据库架构，使得数据之间也相对独立，业务难于处理。
3.测试微服务也相对难。
4.另一个主要挑战是实现了跨越多服务变更，依赖影响太复杂。
5.部署微服务也相对单服务复杂。
API网关相关：
1.客户端和微服务直接通讯？？？？ 直接通讯是否就不能用负载均衡和集群了？？
2.API 网关负责请求路由、组合和协议转换，API 网关通常会通过调用多个微服务和聚合结果来处 理一个请求。它可以在 Web 协议（如 HTTP 和 WebSocket）和用于内部的非 Web 友 好协议之间进行转换。
3.API 网关需要支持各种 通信机制。有时候不只是http通讯
进程间通讯：待续~~~