前言
认真研读了极客时间的微服务文章（https://time.geekbang.org/special/microservice-architecture），整体介绍比较全面，特此记录一下；
1. 服务注册，服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。(Zookeeper、Etcd, Eureka)
2. 服务发现，服务调用方从服务注册中心找到自己需要调用的服务的地址。
3. 负载均衡，服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
4. 服务网关，服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。（开源方案：Spring Cloud Zuul）
5. 配置中心，将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
6. API 管理，以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。(文档：swagger，调用链分析，api测试？)
7. 集成框架，微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
8. 分布式事务，对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。(这个才是整个微服务架构的难点)
9. 调用链，记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
10. 支撑平台，系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。
11、运维：包含自动构建、自动部署、日志中心、健康检查、性能监控等功能。
12、微服务实践：业内成熟方案：Netflix 的微服务方案和 Spring Cloud
思考：如何进行模块化开发
书籍推荐：
参考文档
