如何构建一个简单的Micro Service？
Micro Services
谈微服务之前，首先要看微服务圣经《The Twelve Factors》
SRP：Single Responsibility Principle 单一职责原则。每个服务都要小而美，快速开发迭代。
不局限于开发语言和工具，对于不同的服务请使用最合适的技术和工具。特别是对于新技术的尝试，将影响降到最低年
不限开发团队，不同的服务可以由不同的团队完成。
快速部署/回滚，敏捷度提高，A/B test，轻松替换服务。
对于微服务的应用，可以容易的针对系统瓶颈做自动扩容，同时通过服务治理来降低服务依赖（服务治理是最头疼的）
然而存在一些涉及悖论：
对于DRY（Don't Repeat Yourself），很难实现代码共享和使用相同的技术栈。因此同样的代码/错误可能存在不同的服务中
不能轻松的使用同一个DB。
CAP 原则：一个分布式系统中， Consistency（一致性，同意时刻数据的一致性）、 Availability（可用性，部分节点挂掉后提供客户响应）、Partition tolerance（分区容错性，当数据不一致的时候对对C还是A的选择），三者不可得兼。AP VS CP =>一致性优先VS可用性优先
避免二段提交2PC。
关键技术点
1.IaaS/Paas/CaaS, 不同的选择，对于整体架构的影响是很大的。例如选择了CaaS服务，供应商已经完成的大部分服务编排，容器编排任务
2.Service Management(Service Discovery, Service Registry,Service Monitor)，这东西解决方案太多。Consul，Netflix，docker，rancher等很多软件已经提供了不同的解决方案。
3.Correlation IDs， 由于服务分散到里不同的instance， 提供统一的机制来处理ID至关重要，对于问题回溯和压力分流都能起到不小的帮助。
4.Log Monitoring，服务小而多，甚至每台移动应用（手机里的app）都可能是一个服务，将日志集中处理，且能定位日志来源至关重要。
5.API Gateway，对外提供统一的入口，流量控制，访问控制，访问日志，协议转换。
6.API Management，随之服务的增多，文档和接口不一致，借口变化都换带来其他服务的问题，需要同意的API管理机制。
7.Container Management，容器近年来越来越牛，好的容器编排工具，大大降低团队对于容器的管理成本，让开发团队话更多的时间在业务上，而不是环境上。
8.Configuration Management，不同环境，不同服务之间的配置需要一个统一的管理机制。
一些技术栈堆叠
