部署模式如何部署服务是微服务中的一个重要问题。微服务的部署方式非常灵活，有不同的方案可供选择（参考open-open.com/lib/view/）Multi-servicesharedhost/virtualmachinesingle-servicedeploymentsinglehost/virtualmachinesingle-服务部署单容器（Docker）无服务部署（serverless），如AWSLambda使用服务部署平台（Kubernetes、DockerSwarm、Mesos、AWSECS）不同的部署方式各有优缺点。推荐使用容器编排系统的服务部署平台，可以提供多种灵活的部署方案。横向关注微服务开发往往需要花费大量时间来处理每个服务遇到的问题，比如如何管理配置信息，比如用户名和密码、服务器网络地址等日志管理健康检查业务测量数据（Metrics）收集分析分布式服务追踪这里推荐使用稳定的微服务框架来处理这些问题，比如基于Java的springboot，基于Golang的Micro等API网关。API网关类似于服务代理，所有客户端都通过API网关提供的统一服务API来消费服务内容。以下是几个开源APIGatewayKong(github.com/Mashape/kong)APIAxle(http://apiaxle.com/)Tyk(tyk.io/)apiGrove(http://apigrove.net/)WSO2APIManager(http://wso2.com/products/api-manager/)服务发现服务发现是指API网关或客户端如何获取微服务的地址。主要有以下几种发现方式：客户端发现服务器发现解决方案中的路由器可以纳入API网关，客户端直接与网关通信。两种方案都需要服务注册，区别在于服务注册是否直接暴露给客户端。常见的提供服务发现的注册开源解决方案包括：ApacheZookeeperConsulEtcd断路器当微服务系统中的某个服务出现问题，或者网络出现延迟时，会阻塞调用客户端，从而导致大量ofCalling占用大量资源。这时候就需要引入一个具有断路器作用的proxy。当出现不健康的服务时，断路器将返回错误以阻止更多客户端使用它，直到服务恢复健康为止。netflix的hystrix提供了类似的服务github.com/Netflix/Hyst数据管理在设计微服务时，要考虑每个服务是否有自己的数据库或共享数据库。每个服务都有自己的数据库。共享数据库。各有优缺点：独立的数据库让各个服务完全解耦，可以根据需要选择不同类型的数据库，但服务之间没有办法或者很难共享数据。共享数据库可以简化维护和技术栈，但数??据库成为所有服务的依赖，系统耦合度更高，带来不灵活，没办法根据业务需求选择不同的数据库类型。相对于《设计模式》和《反模式》这本书，你可能对微服务中的反模式了解的少一些。其实同理，反模式总结了一些容易犯的常见设计问题。那么，什么是微服务？反模式呢？聚合和混沌软件设??计的主要思想之一“高内聚、低耦合”同样适用于微服务。太多的依赖。没有认真对待自动化持续集成和交付与微服务齐头并进，自动化测试、集成、交付和部署对于微服务的成功至关重要。自动化程度低的微服务是很难成功的。分层软件架构在设计微服务时，应尽可能避免分层架构，服务之间应进行更多的流式调用。例如，为所有服务提供一个数据访问层数据服务似乎并不是一个好的选择，因为这样的优化使得所有服务都依赖于数据服务。微服务应该更多地基于业务来设计，每个服务都应该是自包含的。下面的架构虽然是分层架构，但也可以采用，前提是不同的服务不要共享数据。依赖客户签收当服务有不同的客户渠道消费时，不应依赖客户签收，自动化测试应覆盖所有使用场景。手动配置管理应尽量避免手动配置管理，实现自动化避免版本管理。在微服务中，如果你的系统只有一个版本，那么这一定是个问题。向前兼容是一个需要支持的目标，这意味着不同的客户端版本不应该受到服务升级的影响。这也意味着API一旦发布，就不应该有不兼容的更改。为每个服务创建一个网关不用说了，看起来很傻参考microservices.io/patterinfoq.com/articles/seve
