【编者的话】本文作者拥有超过12年互联网产品开发和管理经验，专注于互联网技术架构设计，对产品设计、敏捷开发、安全、OKRs、大数据等领域有深入研究。本文介绍微服务架构和优缺点，并讲解常见微服务架构模式和适用场景。最后结合实践，选择合适的云平台，讲解如何部署、管理、迁移和服务伸缩，最后讲解实际运营中的问题及解决方案。
总结优点就是 ：灵活、稳定、省资源
总结缺点就是：服务多，管理难度大
这是以前大家常用的MVC模式，讲究模块化设计和设计模式。
从多个服务的结果聚合到一个聚合服务，最常见的聚合服务是web服务，主要功能是页面表现，后端的服务都是纯业务功能服务，扩展业务只需要增加一个新的后端微服务就可以啦，这个模式是最常用模式。
代理模式是一种特殊的聚合模式，对外是一个统一的包装，一般做内部接口的代理，对外统一一个接口。
可实现部分业务的逻辑分离，数据共享。
用在一体化架构往微服务架构迁移过程中的过度模式。
还可用在两个服务之前有数据一致性要求，通过统一的数据库事务来实现。
适合不需要同步任务返回的服务，比如任务型服务。
这种模式容错性好，性能高。
当然，这是异步本身的优点 比较复杂的业务场景大家可以研究下 CQRS ，核心也是异步。
服务部署的挑战
每个服务都需要 独立的代码管理、版本管理、编译构建、部署到测试环境，部署到生产环境，代码回滚等等事情，如果要有几十个服务要部署，人工管理几乎不可能完成。
服务伸缩的挑战
无状态服务 需要配置负载均衡和增加节点，有状态服务需要扩充单个服务的资源，如果需要减少资源浪费，需要监控每个服务，还需要减少节点和资源。
服务高可用的挑战
每种服务的高可用策略都不一样，无状态服务相对简单，管理每个有状态服务都是难题。
服务容错的挑战
任何一个服务的可用性都不是 100% 的。在分布式系统中，当我依赖的某个服务不可用的时候，我自身也将不能工作 。如果是一个复杂的分布式系统，会依赖更多服务，任何一个服务不可用的时候，系统自身也将不能工作，再加上网络不稳定的因素，系统自身的可用性将大幅度下降。
依赖关系的挑战
依赖配置文件，如果写在代码中，需要重新部署才能生效，而配置文件还会污染代码。
服务监控的挑战
监控cpu？负载？磁盘IO? 大量微服务如何同时监控？什么方式监控更加有效？
好雨云（www.goodrain.com）
一定要让用户简单
内部封装：不用管理计算资源和网络资源，并把某些复杂特性包装在内部。
整体对外：服务做为一个整体管理。
以业务为核心，去除技术多余技术概念。
我们支持 java，php，python，node.js，ruby，golang等开发语言。
如果需要更加灵活的方式 就需要用 dockfile了
源代码支持 github 和 私有代码仓库
以敏捷为主，关键性的服务，可以定制开发部署流程，增加权限限制，符合内审制度。
水平伸缩 用于 无状态的 server 和 worker 类的服务。
垂直伸缩 用于 有状态的服务。
一般通过LB和消息队列支持无状态服务高可用
有状态服务的高可用比较困难，我们通过统一的框架支持。
有点类似spring的依赖注入
类似保险丝，当服务B变慢，达到断路器的阀值，服务B，将自动下线，不至于影响其他服务，当延迟变小，服务逐步恢复。
容错还有一种方式是使用异步。
业务指标：平均响应时间，吞吐率 ，在线人数
在实际场景中，使用业务监控可以替代技术监控，而且更加简单容易理解。
Q&A
Q：请问你是基于Docker和Mesos吗?Q：是混合云架构吗?
A：用了Docker。
Q：微服务是谁发布哪？
A：是的，也可用在私有云。
Q：业务系统日志是如何处理的？
A：只要有代码就可以发布微服务，一般由微服务的开发者发布。
Q：请问你们的容器管理系统是基于开源平台还是自己开发的？有何优势？
A：统一输出到标准输出和错误输出，按租户存储，实时显示到页面，可以按天下载。
Q：请问你们的服务「水平伸缩」和「垂直伸缩」分别面对哪类场景？如何实现？
A：用了一部分开源。
最大的优势是简单和灵活：
1. 减少了很多技术概念，只用管理以业务为核心的应用，使用更加简单
2. 由于架构的灵活性，除了支持微服务架构，还可以支持更加复杂的架构。
3. 好雨云可以跑在任意IAAS上，理论可支持全球数据中心。
4. 支持开源服务和用户贡献的服务，用户选择空间更大。
Q：微服务跨平台如何解决网络延迟问题呢？
A：「垂直伸缩」对于所有场景都是可以使用的。「水平伸缩」用到无状态服务的场景，而且可以和「垂直伸缩」叠加使用的，有状态服务不支持水平伸缩。针对不同微服务类型，在管理后台配置就可以实现。
> A：在网络不稳定的场景，服务之前的调用一定要用断路器，另外只有优化物理网络链路了。
Q：微服务怎么解决后端数据库的部署和依赖问题 ？
Q：介绍下服务间通信是如何实现的？
A：在好雨云，数据库也算特殊一类微服务，同样有其他微服务的特性，一样可以通过微服务的特性部署和配置依赖关系。
Q：支持的语言有没有c语言？
A：在服务使用端实现了一个透明的代理，它根据服务注册的Endpoint，找到要使用的服务，如果是多个服务，自动实现负载均衡。
Q：请问一下docker选用的是哪个版本？有特殊原因么？
A：可以通过dockfile支持的。
Q：请问代理模式是指类似于 API GATEWAY 吗？具体用什么实现的？
A：我们比较保守，用的是比较稳定的，除非有个大特性吸引我们
Q：从前面架构图看每个微服务的数据库是独立的，这是必须的吗？
A：是的。有很多种实现方式，可以自己写代码实现，也可以部署一个 Nginx。
Q：能否理解解决「服务伸缩」问题的重点是「服务发现」和「状态共享」？
A：这样有很多优点，比如业务隔离，独立团队维护，业务分区，等等，不是必须，共享模式就是特例。
Q: 请问当每个服务都可能同时存在多个在线版本时，如何做ab testing？如何控制业务路由？
A：这块的核心依赖程序实现，如果程序实现的好，就可以做到非常好的水平伸缩，我们自己的有状态服务也是可以水平伸缩的。
Q： 哪种服务模式用的最多？异步消息模式吗？
A：ab testing 我们当前没有实现，下一步会引入这个特性。我们的设计思路是实现一个控制用户访问路由的微服务，同时支持ab testing。
Q：微服务后端的数据库是弹性伸缩的怎么做的？MySQL，mongodb
A：用的最多的是聚合模式和异步消息模式。
Q：伸缩的时候对业务可以做到完全透明吗！
A：要支持水平伸缩，需要部署一个支持水平伸缩的数据库中间件做为微服务。
垂直伸缩，直接调整资源就可以了，受限于物理机的资源容量。
Q：服务发现用到什么，Consul、Dubbo？
A：是的。我们现在的实现是对业务完全透明。
Q：每个微服务对应一个数据库，怎么做到数据共享呢？
A：轻量级封装 etcd。
Q：垂直伸缩，调整资源就可以了，资源需求超过一台物理机呢？拆库？
A：每个微服务后面的数据库支持有状态数据的持久化，对外整体是一个业务服务，需要根据业务关系来梳 理服务结构。如果有一致性要求比较高的场景，可以使用共享数据库或消息服务实现。
Q：服务调用链的事务怎么保证的？
A：三种方式：第一种，把业务拆的小，数据库分库。第二种，数据库 sharding。第三种，使用CQRS模式，重新设计实现。
Q：CQRS 模式的 维护成本很高啊 有评估过这种改造的成本吗？
A： 可以通过共享数据库，使用数据库事务解决调用链事务问题。 另外，还可以使用异步的消息服务，通过保证消息可靠消费来实现。
Q：能分享下如何把控提供微服务的细粒度，微服务的范围和边界怎么控制？
A： 有框架重用的，比如AKKA，性能奇高，开发也很简单。只是学习曲线比较陡
===========================================================
A： 一定要结合实际业务场景，还要看团队情况，我的经验是，微服务的粒度和内部人员管理关联。随着业务发展，粒度也需要不断调整的。边界要考虑业务抽象的合理性。
以上内容根据2015年11月24日晚微信群分享内容整理。分享人：刘凡，好雨云创始人兼CEO。曾任澳客网 CTO和CEO职位。拥有超过12年互联网产品开发和管理经验，专注于互联网技术架构设计，对产品设计、敏捷开发、安全、OKRs、大数据等领域有深入研究。推崇反应式编程，并在多个产品中成功应用。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesx，进群参与，您有想听的话题可以给我们留言。
有疑问加站长微信联系（非本文作者）
