分布式服务架构案例

1.分布式系统的架构演变过程

• 单机系统

• 集群架构
  

• 系统拆分，业务垂直化
  

• SOA服务化架构
  

• 微服务架构
  

2.系统服务化需求

• 服务化与rpc协议：
  一次RPC调 用主要需要经历的三个步骤 :
  1.底层的网络通信协议处理
  2.解决寻址问题
  3.请求/响应过程中参数的序列化和反序列化工作

• rpc调用流程图：
  

• 阿里分布式服务框架 Dubbo 实现服务化
  1.dubbo服务调用流程图
  

  2.要警惕 Dubbo 因超时和重试引起的系统雪崩
  3.还有一点很重要 ， 并不是任何类型的服务都适合 Failover 的，比如写服务，由于 需要考虑幕等性，因此笔者建议调用失败后不应该进行重试，否则将导致数据被重 复写人。只有读服务开启 Failover才会显得有意义，既然不需要考虑幕等性，就可以 通过 Failover来提升服务质量。

• 服务治理方案
  1.服务的动态注册与发现
  2.服务的扩容评估
  3.服务的升/降级处理。

• 服务化的分布式事物
  其实分布式事务一直就是业界没有彻底解决的一个技术难题，没有通用的解决 方案，没有高效的实现手段，但是这并不能成为我们不去解决的借口。网络上有一 句非常著名的段子，“此处不留爷，自有留爷处:处处不留爷 ，爷走出国路”，既然 分布式事务实施起来非常困难，那么我们为什么不换个思路，使用其他更优秀的替 代方案呢?只要能够保证最终一致性，哪怕数据会出现不一致的短暂窗口期又有什 么关系?在架构的演变过程中，哪个是主要矛盾就优先解决哪一个，就像我们对 NM 进行性能调优一样，吞吐量和低延迟这两个目标本身就是相互矛盾的 ，如果吞吐量 优先，那么 GC 就必然需要花费更长的暂停时间来执行内存回收 ;反之，频繁地执行内存回收，又会导致程序吞吐量的下降，因此大家要学会权衡和折中

3.分布式调用跟踪系统

• 错综复杂的服务依赖关系
  

• 几大知名的服务调用跟踪系统：淘宝的鹰眼( EagleEye)、 Twitter 的 Zipkin、新浪的 Watchman，以 及京东的 Hydra等

• Google 的 Dapper论文中涉及的关于分布 式调用眼踪系统的一些关键设计目标
  1.服务性能低损耗;
  2.业务代码低侵人;
  3.监控界面可视化;
  4.数据分析准实时。

• 调用跟踪系统的两个基础功能
  1.跟踪每个请求的完整调用链
  2.收集调用链上每个服务的执行耗时，以及整合孤立日志。

• 采样率方案：更能做到低损耗

4.总结

如果用户规模及业务需求的复杂度还没有到量，那么最好保持现有架构 不变，毕竟构建一个高性能、高可用、易扩展、可伸缩的分布式系统绝非一件简单 的事情，需要解决的技术难题太多。而且，如果业务没有起色，一昧地追寻大型网 站架构并无任何意义。当然，随着用户规模的线性增长，以及业务需求越来越复杂， 从单机系统逐渐演变为分布式系统，以更好地支撑业务发展似乎是必经之路。