微服务架构很热，讨论的文章非常多。但如果提到微服务架构的云端应用，可以深入分析的还比较少。本篇来自中生代技术群（freshmantechnology）第二期，好雨云创始人兼ceo刘凡的分享。其曾任澳客网 cto和ceo职位。拥有超过12年互联网产品开发和管理经验，专注于互联网技术架构设计，对产品设计、敏捷开发、安全、okrs、大数据等领域有深入研究。现推崇反应式编程（http://www.reactivemanifesto.org/），并在多个产品中成功应用。
下为正文：
微服务的优点：
可独立部署、升级、替换、伸缩
自由选择开发语言
高效利用资源
故障隔离
总结下来就是：灵活、稳定、省资源。
微服务的缺点：
服务多，带来更多操作
管理复杂度提升
部署难度加大
总结就是：服务多，管理难度大。
仅管微服务存在着缺点，但它的优点也是非常吸引人的，目前很多企业也逐渐开始了微服务架构之旅，包括像twitter,netflix,amazon,ebay等大厂商都在使用。如下图是twitter微服务应用部分架构图。
传统mvc架构，也是一体化模式。
从多个服务的结果聚合到一个聚合服务，最常见的表现是聚合服务是web服务，主要功能是页面表现，后端的服务都是纯业务功能服务，扩展业务只需要增加一个新的后端微服务就可以啦。
聚合服务也可以是一个更高层次的组合微服务，增加业务逻辑后进一步发布成一个新的微服务，这符合dry原则。另外，每个服务都有自己的缓存和数据库。这个模式是最常用模式。
可实现部分业务的逻辑分离，数据共享。
用在一体化架构往微服务架构迁移过程中的过度状态。还可用在两个服务之前有数据一致性要求，通过统一的数据库事物来实现。
上面的其它模式都是同步的，会阻塞。异步消息模式适合不需要同步的场景，比如任务型服务。
主要的模式就这些，其它模式可以由这些模式演变。
每个服务都需要独立的代码管理、版本管理、编译构建、部署到测试环境，部署到生产环境，代码回滚等等事情，如果要有几十个服务要部署，人工管理几乎不可能完成。
无状态服务需要配置负载均衡和增加节点，有状态服务需要扩充单个服务的资源，如果需要减少资源浪费，需要监控每个服务，还需要减少节点和资源。
每种服务的高可用策略都不一样，无状态服务相对简单，管理每个有状态服务都是难题。
任何一个服务的可用性都不是 100% 的。在分布式系统中，当我依赖的某个服务不可用的时候，我自身也将不能工作。如果是一个复杂的分布式系统，会依赖更多服务，任何一个服务不可用的时候，系统自身也将不能工作，再加上网络不稳定的因素，系统自身的可用性将大幅度下降。
依赖配置文件，如果写在代码中，需要重新部署才能生效，而配置文件还会污染代码。
监控cpu？负载？大量微服务如何同时监控？
微服务在云端的解决方案
底层是通过docker实现的，只是用户感受不到docker。
内部封装,不用管理计算资源和网络资源，并把某些复杂特性包装在内部。整体对外，服务做为一个整体管理。
开发语言支持java、python、php、ruby、golang,node.js等，代码支持github，好雨托管仓库。
水平伸缩用于无状态的 server和worker 类的服务。
垂直伸缩用于有状态的服务。
部分有状态服务支持水平分区（ sharding），用户只需要调整节点个数就可以了。
一般通过lb支持无状态服务高可用，支持有状态服务高可用。
类似spring，参数通过环境变量实现。
实现微服务之间的连接和编排，以上微服务模式都可以通过这种方式动态配置实现。
类似保险丝，当服务b变慢，达到断路器的阀值，服务b，将自动下线，不至于影响其他服务，当延迟变小，服务逐步恢复。容错还有一种方式是使用异步，可以参考cqrs模式。
业务指标：平均响应时间，吞吐率 ，在线人数。
在实际场景中，使用业务监控可以替代技术监控，而且更加简单容易理解。
单个rest服务的实时性能分析，数据库性能分析，最慢的sql语句不一定是对数据库影响最大的。实时性能分析通过cep＋log实现，以前工作一直使用，没有apm炫，但解决了很多实际问题。还在实现了mongodb ，redis等数据存储的实时性能分析。
至此，相信你也对微服务，微服务的构架模式以及微服务在现实场景中的应用有了一个大概的认识了。如果你还想要了解得更多，请继续查看下面的q&a环节内容。
q1 99.95%的sla是如何测量的，现在都有那些初始客户?
刘凡: 我们自己实现了负载均衡组件，监控每个租户的服务可用性，后端服务不可用和错误返回码都会算到不可以用时间。我们现在的用户有工行，天津滨海新区管委会，章鱼网，51talk，学霸君，好贷宝等。
q2 依赖调整配置就生效吗，背后是如何做到的？
刘凡: 我们的服务发现是通过etcd实现的，之前实现了完全实时修改实时生效的方案，但是太复杂了，现在的实现方式是通过环境变量实现的，修改配置之后需要重启，无状态服务用户感知不到。
q3 soa的时候重点谈到了美好的编排，不同粒度的层次，逐层编排，其实最考验设计能力和抽象能力，编排本身的美好得不到很好的利用，如何破？
刘凡: 这只能考验一个公司的技术架构师和业务架构师了，我以前身兼这两职，我没遇到过这些问题。我也没有其它思路。
q4 监控部分对于内存泄漏，堆栈分析有没有好的支持？
刘凡: 这个没有，但是如果由于内存泄漏导致服务死掉，我们平台会自动重启。
q5 你们云平台本身有没有异地容灾的能力？
刘凡: 我们能实现geo－master，现在设计如何对用户开放这类服务。
q6 微服务这块在移动端有没有好的案例，一般像android和 ios这类移动应用上如何使用和借鉴微服务模式呢?
刘凡: 刚才分享的代理模式特别适合用户移动开发场景，微服务都是api。代理模式是一种特殊的聚合模式，对外是一个统一的包装，一般做内部接口的代理，对外统一一个接口，内部可以用多个微服务实现。
q7 服务之间有没有调用链的设计，方便跟踪跨服务的问题，可以分享一下吗？
刘凡: 细化的跟踪没有，通过服务拓扑可以实现粗力度的。
q8 工行上的是那些业务，好雨云擅长是高性能高pv的业务，还是对事务一致性要求都有很高要求的业务？
刘凡: 高pv场景我们特别适合，因为我们非常容易伸缩。事务一致性我们有两种方式，一种大家可以选择自己喜欢的存储服务，各类数据有存储自己的方式。第二种，我们通过akka实现一套高一致性，高性能的解决方案，单机能做到每秒100万的事务。
q9 你提到了类似在线人数之类的业务监控，对于产品可以增强链路监控功能否，比a9如用户是在操作链路上那个环节流失得比较严重，做统计以便产品改进，这些监控本身需要调用平台api吗？
刘凡: 不太理解链路是什么意思，是指用户行为数据吗？现在我们没有，我们不擅长这块。
q10 服务拓扑就是服务级依赖关系吧？
刘凡: 是的，每个微服务有自己的响应时间和吞吐率，表现在拓扑图里，可以粗力度分析出问题。
q11 我们通过akka实现一套高一致性，高性能的解决方案，单机能做到每秒100万的事务，这块能不能具体说一下，比如一个第三方支付简单的a用户到b用户的转账场景，a和b在不同的sharding单元。
刘凡: akka的模式是使用cqrs模式，也就是事件溯源的方式，以前数据库的那些事务问题在这都不存在。
q12 akka的话是不走数据库直接在内存里做事务吗？
刘凡: 是的，通过事件溯源保证数据一致性。理论上它不是事务，但能实现事务的效果。
q13 队列技术如何支持的呢？
刘凡: 我们平台支持任何开源的队列服务。
q14 微服务之间如何通信，协议和数据格式是怎样的？
刘凡: 微服务会有多个节点，但我们会内置lb，对外统一一个服务接口，支持任意协议和格式。
q15 工行，天津滨海新区管委会，章鱼网，51talk，学霸君，好贷宝主要应用场景，高pv支持，高事务支持，大数据分析，爬虫，devops，通过微服务架构把业务能拆分更小，便于重用和维护。 akka的方案就是联机交易。这些客户具体的应用场景是哪些呢？可以选择1－2个典型case介绍下微服务所产生的价值，如果有联机交易的case更佳。
刘凡: 介绍下微服务所产生的价值，如果有联机交易的case更佳主要应用场景，高pv支持，高事务支持，大数据分析，爬虫，devops，通过微服务架构把业务能拆分更小，便于重用和维护。 akka的方案就是联机交易。
q16 实时性能分析用的是cep +log, 不是很理解cep？
刘凡: 复杂事件处理，实时流处理，通过strom也可以实现。
q17 如何应对微服务的毛剌现象（某个服务瞬间出现较大延迟的现象，可能会导致某批请求超时等情况）？
刘凡: 不好意思，我没遇到过这种情况，我觉得应该跟实现方式有关。
q18 akka的方案就是联机交易，akka原先架构体系是什么？遇到了什么样的瓶颈？微服务之后改进的是什么？联机交易规模怎样？
刘凡: 原先就是用传统数据库，交易的事务性能低下，做了sharding会引入新的问题，而且联机分析也有问题，用akka改造后能处理高峰业务每秒10万左右的事务。
<b> </b>