微服务讲堂---【3】分布式架构

在写下其他文字之前，必须先声明下，这篇文章不是介绍讨论关于分布式技术的，而是讨论分布式架构在微服务架构中的价值和弊端。分布式技术经过多年的发展，已经相对很成熟，相关文章很多，所以不是本文的重点。

在阅读下文之前，我推荐先阅读以下三篇文章，特别是最后一篇，有比较完整的阐述。

1. http://2012.33degree.org/pdf/JamesLewisMicroServices.pdf
2. https://archive.oredev.org/oredev2012/2012/sessions/micro-service-architecture.html
3. https://martinfowler.com/articles/microservices.html

 

微服务天生是分布式，这跟具体的实现措施没有关系，而是根据他的定义来看，就应该是这样的。之前我也谈过，微服务的核心在于一个“微”字，这个方法带来了很多好处，就像现在工业化的分工合作一样，越来越细致；但也带来了之前没有遇到的问题，就是进程多，也因此导致了管理上的难度。

Martin Fowler在阐述微服务的时候，强调了去中心化治理和去中心化数据管理，这和分布式架构是不谋而合的。但我们也必须看到，分布式架构即使发展这么多年过去，还是没有被业界广泛采用，不是没有原因的。

分布式架构在整体的技术难度上来讲，远远超过了其他架构，而是被频繁的应用于某些基础组件中，比如分布式文件系统，GFS。更在技术难度较低的业务系统，并没有太多的应用。Martin Fowler为此也补充说，基础设施自动化。微服务的核心在于一个“微”字，由此导致了一个“多”字，即服务多了。之后发展起来的调度、治理以及自动化，都是为了解决这些问题。

讲个真实遇到的小故事，有次听人介绍他公司产品的时候，说他们很早前采用了微服务架构。我很好奇地问了句，你们有多少个进程？20多个！嗯，是我哪里理解有问题吗？

微服务必须是分布式吗？其实不见得。这需要仔细权衡业务现状和成本问题。分布式的技术难度必然导致了研发成本和时间居高不下，如果只有20多个服务进程的业务，去搞微服务架构也要硬套上分布式技术，除了太有钱想不开外，更大的可能是对投资人不负责任。

微服务必须是HTTP API吗？我很反对这个说法。虽然说，互联网是最大的分布式系统，HTTP协议功不可没。但在微服务架构中普遍采用HTTP API，即使是RESTFUL也是很危险的想法。HTTP以同步调用模式为主，即使后面异步模式有所发展，但支持并没有那么友好。微服务因为调用链变长，所以服务失效的风险指数增大，学过概率统计的人可以自己计算下。在一个变长的调用链中，嵌入同步调用模式，后果可想而知。让HTTP API作为一种网关协议，在靠近最终用户的地方，可以是被调用才是最好的方式。

基于MQ是一种很好的微服务实践方式。MQ以消息作为数据交换协议，和HTTP+json等可以进行良好的转换，而且也支持PRC模式。更重要的是，MQ是异步和长连接模式，在吞吐量、延迟以及异常捕获方面都由于HTTP模式。因此，在系统内部以MQ为主，在系统边界处支持HTTP/RPC等其他方式，让整个系统具备更好的兼容性。

在MQ早期发展中，主要以集群方式出现的，比如SOA架构中ESB之类的。在持续发展中，分布式总线也得到了发展，甚至在早前微服务出现之前，就已经出现了分布式总线产品。以哪种MQ作为基础组件，还是要考虑产品和团队的现状来做决定的。

在微服务架构发展到现在，已经出现了很多开源项目，比如spring系列，降低了企业实践微服务的技术难度，成本也没有早前难以接受。但在后期维护的难度和成本依然不容小觑，特别是在生产环境中出现故障，那么基础设施的故障会导致难以承受的代价。

分布式架构是微服务架构的优秀实践，但是否要按照这个方式来实践，要充分考虑自身的现状，在成本和效果之间进行有效的权衡。