对两者的东西进行区分以及比较，有时候是源于两者有许多的共同之处。两者概念上不同，可解决的问题的复杂程度不一样。但是区分两者的不同之处是更有易于实现微服务架构和分布式架构的最大价值。用户选择使用何种架构的时候，得需要根据自己的实际情况进行选择。

从概念理解，分布式服务架构强调的是服务化以及服务的分散化，微服务则更强调服务的专业化和精细分工;从实践的角度来看，微服务架构通常是分布式服务架构，反之则未必成立。所以，选择微服务通常意味着需要解决分布式架构的各种难题。

微服务架构是团队面对互联网产品爆发式增长的最优选择，要解决的是快速迭代、高可靠和高可用等问题，把复杂度很高的产品拆分成一些较小的模块，并遵循康威定律，每一个模块用5-9个小团队来维护，这样可以减少沟通成本，提高协作效率，更好地实现快速迭代和弹性扩展。比如网易考拉，先用网易内部的私有云以及容器服务、负载均衡等解决并发流量的问题，再借助网易云轻舟微服务，拆分了 400 多个工程(模块)，进一步提升迭代速度和扩展能力，通过服务治理、系统运维自动化等，可以提升可靠性和可用性。这是先有分布化后有服务化的例子。

网易考拉微服务改造及效果

既没有规模又不需要太多变化的业务，如果采用微服务架构改造，引入各种复杂性，比如部署工作量的增加、复杂链路的监控难题，这就是为微服务而微服务，只会得不偿失。

当然，复杂业务拆分可能无法一步到位，因为复杂，每个业务并不一定只能拆成一个组件，庞大的业务拆分出相对独立和庞大的业务，但如果业务较小而又比较多，且类型相似，也可以不用着急拆分。再举网易考拉的例子，工程数量由最初的 7 到后来的 150+ 再到目前的 400+，都是根据实际情况决定的。中间的状态，可能不是严格意义上的微服务架构，但属于分布式服务架构——不过这不是那么重要，重要的是符合业务发展阶段的需求。医院的急诊，既看发热又看胃痛，固然分工没那么精细，但我们也不能说就是错的。

这是对微服务架构和分布式架构的区别与联系简要地介绍，不过都是为对象是服务的，但通过一些对象的使用的情况来看的话，它于不同的服务对象所带来的效果是不一样的。因为它们需要考虑两者的数量以及服务对象以及业务的需求。想要了解更多关于软件研发的信息，请继续关注中培教育。