微服务架构的云端应用

什么是微服务架构

微服务架构（Microservices Architecture）是将应用拆分成小业务单元进行开发和部署，使用轻量级协议通信，通过协同工作实现应用逻辑的架构模式。

灵活、稳定、省资源是微服务架构的主要优点——

• 可独立部署、升级、替换、伸缩
• 自由选择开发语言
• 高效利用资源
• 故障隔离

服务多、管理难度大是微服务架构的不足之处——

• 服务多，带来更多操作
• 管理复杂度提升
• 部署难度加大

但总体来说，微服务架构是非常吸引人的，否则也不会得到像Twitter、Netflix、Amazon、eBay等知名大厂的青睐。

微服务架构模式

微服务架构模式主要可分为：

• 聚合模式
• 代理模式
• 资源共享模式
• 异步消息模式

聚合模式

聚合模式即多个服务聚合到一个服务，称之为聚合服务。聚合服务最常见的表现是Web服务，主要功能为页面表现，后端服务为纯业务功能服务。也就是说，聚合模式下扩展业务只需增加一个新的后端微服务即可。

聚合服务符合DRY原则，可以是一个更高层次的组合微服务，增加业务逻辑后进一步发布成一个新的微服务，同时每个服务都有自己的缓存和数据库。

聚合模式是微服务架构中最常用的模式。

代理模式

代理模式是一种特殊的聚合模式，即对外将服务统一包装。代理模式可以仅仅委派请求，也可以进行数据转换工作。

我们可以将代理模式比做通过收发室统一收发信件的小区，无论是外部请求还是内部数据服务，均由代理处理。

资源共享模式

微服务架构的资源共享模式可实现部分业务的逻辑分离、数据共享。

资源共享模式常用在“一体化架构”向“微服务架构”迁移的过渡阶段，以及有数据一致性要求的两个服务。

异步消息模式

微服务架构的异步消息模式适用于不需要同步的场景，如任务型服务，利用消息队列代替其他微服务架构模式所采用的REST请求及响应。

微服务架构带来的挑战

1. 服务部署的挑战

   每个服务都需要独立的代码管理、版本管理、编译构建、测试环境部署、生产环境部署、代码回滚等，人工管理大量微服务几乎是一个不可能完成的任务。

2. 服务绅缩的挑战

   无状态服务需要配置负载均衡和增加节点，有状态服务需要扩充单个服务的资源。为了减少资源浪费，开发者需要监控每个服务，并在必要的时候减少节点和资源。

3. 服务高可用的挑战

   每种服务的高可用策略都不一样，这其中无状态服务的管理相对简单，而每个有状态服务的管理则是一个难题。

4. 服务容错的挑战

   任何一个服务的可用性都不是100%的，在分布式系统中，当某个依赖服务不可用时，系统自身也将不能工作。尤其是依赖大量服务的复杂的分布式系统，以来服务的可用性加上网络不稳定的因素，系统自身的可用性很可能无法得到令人满意的保障。

5. 依赖关系的挑战

   如果将依赖配置文件写在代码中，需要重新部署才能生效，而配置文件还可能会污染代码。

6. 服务监控的挑战

   监控CPU还是负载？大量微服务的出现也是对服务监控的严峻考验。

好雨的微服务架构解决方案

好雨的微服务架构解决方案(www.goodrain.com)核心思路为——

• 简化用户操作
• 微服务内部封装、整体对外
• 包装技术、服务业务

好雨云底层是通过Docker实现，并尽可能做到让用户感受不到Docker的使用体验。在好雨云，复杂特性被包装在了内部，通过服务整体对外，用户无需管理计算资源和网络资源。

服务部署

好雨云支持Java、Python、PHP、Ruby、Golang,Node.JS等主流开发语言，并支持Github、好雨托管仓库等代码仓库。

服务伸缩

好雨云支持服务伸缩，其中水平伸缩用于无状态的Server和Worker类服务，垂直伸缩用于有状态的服务。

部分有状态服务支持水平分区（Sharding），用户只需要调整节点个数就可以了。

服务高可用

好雨云通过高可用调度器，使无状态服务、有状态服务具备高可用特性。

依赖关系

好雨云的依赖关系解决方案类似于Spring的依赖注入，参数通过环境变量实现，调整服务的依赖关系只需要界面点击即可完成。

服务容错

好雨云的服务容错原理类似于保险丝，当某一服务变慢，达到断路器的阀值，该服务将自动下线，不至于影响其他服务，而当延迟变小时，该服务逐步恢复。

使用异步也可以达到服务容错的效果，具体可参考CQRS模式。

服务监控

好雨云将平均响应时间、吞吐率、在线人数等业务指标用于服务监控。

用业务监控替代技术监控，实际场景中的服务监控得以变得简单而易于理解。

实时性能分析

最慢的SQL语句不一定是对数据库影响最大的，好雨云的实时性能分析通过CEP＋log实现，从实际出发解决问题，开发者可以很直观的了解当前对系统影响最大的URL是哪个。