【好书推荐】微服务与单一服务架构的拼杀，如何选？

fire_cpp

1. 如何理解微服务，简要说明您所理解的微服务是什么？
万变不离其宗，都是向着模块化、标准化、高内聚低耦合的工程优化方向前进。人类各工程史无不如此发展。这东西没有具体的定义，你可以将系统做成几个独立的程序，互相之间通过REST API通讯，你能说不是微服务？但如果没有服务注册、发现、降级、断路、自动测试和部署等的配合，你可能有点不好意思说这是微服务“架构”。但它本质上就是一个微服务构成的系统，只要你做了解偶与业务边界的划分。

2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？
可能没有做过的人并不能充分了解这些优劣。举两个我自己的例子：

一个是用Django开发的Web，所有的功能全在一个Django工程中完成。各功能间没有任务通讯开销，测试也非常顺畅，开发速度还是很快的，也不会出现各子系统间需要通过约定来约束接口和数据结构的情况，一个全局定义所有模块全部生效。但如果想改一个功能，必须将一个服务全部停掉才能更新。

另一个是微服务架构而成的系统，不同部分分别用了Django/Go/C++，互相之间除了通过REST接口通讯，部分还选择通过消息队列进行通讯。做单个服务的时候，是挺顺畅的，理解起来也没有阻碍，出了问题不用调试我都知道可能是哪出了问题。只是你做到D服务的时候，可能会把A、B、C服务的实现给忘了，互相之间只有约定好的接口，不看文档做根本不放心。而且，有些测试比单体服务困难，不是说构建测试困难，而是各服务之间的关系有时难以处理，有时端到端测试几乎是不可能的。你说这到底是降低是软件质量还是提高了软质量？很难说。但带来的好处也很明显，我可以单独部署、单独完成，选择合适的技术栈，横向扩展也非常方便。测试大多数时候还是比单体服务要方便的。

3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？
最麻烦的，我觉得是测试。两三个关系不复杂的服务还好办，如果七八个服务，几十个接口，各种异步、并发，关系错综复杂，有些自动化测试根本没办法进行，或者成本极高。如果自动化测试没法进行，devops就谈不上。

另外的难点，就是服务粒度的划分，这是没有标准的，全看需求、凭经验。总地来说，前期粒度大一些，后期可以慢慢改小，但哪些可以合并到一起、哪些必须在前期就要分开，很考经验。

最后的难点，就是围绕微服务架构上的那一套了，比如服务注册、发现、降级、自动化测试和部署等等，真的全套做下来成本不低的，多数小团队没有精力去实施的。