什么是微服务架构
微服务架构（Microservices Architecture）是将应用拆分成小业务单元进行开发和部署，使用轻量级协议通信，通过协同工作实现应用逻辑的架构模式。
灵活、稳定、省资源是微服务架构的主要优点——
- 可独立部署、升级、替换、伸缩
- 自由选择开发语言
- 高效利用资源
- 故障隔离
服务多、管理难度大是微服务架构的不足之处——
- 服务多，带来更多操作
- 管理复杂度提升
- 部署难度加大
但总体来说，微服务架构是非常吸引人的，否则也不会得到像Twitter、Netflix、Amazon、eBay等知名大厂的青睐。
微服务架构模式
微服务架构模式主要可分为：
- 聚合模式
- 代理模式
- 资源共享模式
- 异步消息模式
聚合模式
聚合模式即多个服务聚合到一个服务，称之为聚合服务。聚合服务最常见的表现是Web服务，主要功能为页面表现，后端服务为纯业务功能服务。也就是说，聚合模式下扩展业务只需增加一个新的后端微服务即可。
聚合服务符合DRY原则，可以是一个更高层次的组合微服务，增加业务逻辑后进一步发布成一个新的微服务，同时每个服务都有自己的缓存和数据库。
聚合模式是微服务架构中最常用的模式。
代理模式
代理模式是一种特殊的聚合模式，即对外将服务统一包装。代理模式可以仅仅委派请求，也可以进行数据转换工作。
我们可以将代理模式比做通过收发室统一收发信件的小区，无论是外部请求还是内部数据服务，均由代理处理。
资源共享模式
微服务架构的资源共享模式可实现部分业务的逻辑分离、数据共享。
资源共享模式常用在“一体化架构”向“微服务架构”迁移的过渡阶段，以及有数据一致性要求的两个服务。
异步消息模式
微服务架构的异步消息模式适用于不需要同步的场景，如任务型服务，利用消息队列代替其他微服务架构模式所采用的REST请求及响应。
微服务架构带来的挑战
-
服务部署的挑战
每个服务都需要独立的代码管理、版本管理、编译构建、测试环境部署、生产环境部署、代码回滚等，人工管理大量微服务几乎是一个不可能完成的任务。
-
服务绅缩的挑战
无状态服务需要配置负载均衡和增加节点，有状态服务需要扩充单个服务的资源。为了减少资源浪费，开发者需要监控每个服务，并在必要的时候减少节点和资源。
-
服务高可用的挑战
每种服务的高可用策略都不一样，这其中无状态服务的管理相对简单，而每个有状态服务的管理则是一个难题。
-
服务容错的挑战
任何一个服务的可用性都不是100%的，在分布式系统中，当某个依赖服务不可用时，系统自身也将不能工作。尤其是依赖大量服务的复杂的分布式系统，以来服务的可用性加上网络不稳定的因素，系统自身的可用性很可能无法得到令人满意的保障。
-
依赖关系的挑战
如果将依赖配置文件写在代码中，需要重新部署才能生效，而配置文件还可能会污染代码。
-
服务监控的挑战
监控CPU还是负载？大量微服务的出现也是对服务监控的严峻考验。
好雨的微服务架构解决方案
好雨的微服务架构解决方案核心思路为——
- 简化用户操作
- 微服务内部封装、整体对外
- 包装技术、服务业务
好雨云底层是通过Docker实现，并尽可能做到让用户感受不到Docker的使用体验。在好雨云，复杂特性被包装在了内部，通过服务整体对外，用户无需管理计算资源和网络资源。
服务部署
好雨云支持Java、Python、PHP、Ruby、Golang,Node.JS等主流开发语言，并支持Github、好雨托管仓库等代码仓库。
服务伸缩
好雨云支持服务伸缩，其中水平伸缩用于无状态的Server和Worker类服务，垂直伸缩用于有状态的服务。
部分有状态服务支持水平分区（Sharding），用户只需要调整节点个数就可以了。
服务高可用
好雨云通过高可用调度器，使无状态服务、有状态服务具备高可用特性。
依赖关系
好雨云的依赖关系解决方案类似于Spring的依赖注入，参数通过环境变量实现，调整服务的依赖关系只需要界面点击即可完成。
服务容错
好雨云的服务容错原理类似于保险丝，当某一服务变慢，达到断路器的阀值，该服务将自动下线，不至于影响其他服务，而当延迟变小时，该服务逐步恢复。
使用异步也可以达到服务容错的效果，具体可参考CQRS模式。
服务监控
好雨云将平均响应时间、吞吐率、在线人数等业务指标用于服务监控。
用业务监控替代技术监控，实际场景中的服务监控得以变得简单而易于理解。
实时性能分析
最慢的SQL语句不一定是对数据库影响最大的，好雨云的实时性能分析通过CEP＋log实现，从实际出发解决问题，开发者可以很直观的了解当前对系统影响最大的URL是哪个。
有疑问加站长微信联系（非本文作者）
