27 | 微服务架构：微服务究竟是灵丹还是毒药？

初次了解中台这个概念的时候，觉得他与微服务没有什么不同……但深入对比了解后还是发现了区别 王健老师总结说：中台是企业级能力复用平台 首先中台是对于企业来说的，在我理解是面向企业的设计，并不是服务于仅仅一天业务线而言的 能力指其功能模式，承载手段的多样，比如数据中台等等 复用是指中台对前台复杂多变需求的抽象，在稳定的后台和多变的前台中磨合的齿轮，是树根和枝叶间沟通反哺的树干 而平台是他的存在形式 区别在于 微服务更多的是面向技术，为了代码复用，而没有解决前台的多变的需求 而中台则是面向用户，面向需求，满足用户多变的需求提供稳定的解决方案 微服务是拼凑，微服务面向后台的稳定 中台是抽象，中台面向前台的多变

老师请教一下，微服务之间的http调用是否违反了依赖倒置原则呢？

我想微服务是业务层面低耦合高内聚的体现！ 中台虽然不是很清楚，但我觉得中台第一是要业务量够大，产品或者服务形成矩阵时，抽出稳定的基础共性东西形成支撑上层灵活产品的基础。关键还是对业务的深刻理解，对软件未来的清晰认识，进行边界清晰的业务模块划分，从而形成一套稳定的微服务组成的系统

老师这篇关于微服务的文章，写的太棒了！是否选择使用微服务不能只从技术的角度考虑，应该从架构的层面，我觉得软件架构的本质就是商业利益。正如老师在文章中讲到，单体架构发展到一定程度，业务功能越来越多，开发团队越来越庞大，带来的问题就是面对一个大而全的应用包，开发人员奔溃，集成人员迷茫，测试人员幽怨。新人很难快速上手，太多无效的通宵，牵一发动全身，然后就是各种扯皮。集成人员合并的时候看花了眼，开发人员莫名背锅，本来好好的功能，代码没动过，发一次版本就出问题了。这些问题都会造成效率低下，最终影响到公司和大家的利益。从需求和痛点出发去考虑微服务架构的改造和实践，才是正确的方向！而不能把微服务作为技术和工具来看。牛掰的技术千篇一律(第一性原理)，合适的架构才是目的。

最近代码重构时提出了小前台大中台的概念,说下我的理解: 中台:公司业务方向比较多,对于业务处理逻辑相同的模块想要抽取出来做成一个中台微服务,供所有需要此业务逻辑的微服务调用,如短信模块,物流模块,账单对账等. 微服务:微服务给中台提供了便利,之前对于复用代码需要复制进去,现在有了微服务,这部分直接以微服务形式存在,就不需要去动这部分代码了.有新需求新功能只需要编写与页面交互的代码即可,其余直接远程调用中台. 老师讲的微服务就是应用按模块拆分后的独立部署的一个个模块,我的理解中台只是其中一个复用模块, 提供业务实现的,而微服务技术是实现中台的方式.

我觉得中台更偏底层和工具化一点，微服务是和业务有关联的，而中台一般不会好业务挂钩。现在很多中小企业都在做微服务和中台，完全就是盲目跟风，我觉得还是应该从实际出发，有些用户量不大的应用，没有必要做成微服务。

最近也看了很多关于中台的文章，中台区别于微服务的很多是组织架构上的调整，而微服务不涉及组织架构。中台是为了更灵活快速的试错而提出来的

据说元数据驱动设计模式(metadata driven design), 可以把业务抽象成通用模型，具体使用时，再把模型实例化，从而实现业务的复用，这种元数据驱动设计模式和微服务有什么关系吗？

我们公司就是写中台的，在我的理解，微服务是实现中台的技术，通过把共用业务逻辑抽取出来成为一个微服务中心，供前台调用。

微服务是一种技术实现方式，通过分业务/技术模块分别管理和部署来减少耦合，提升能力复用程度。中台是面相业务，最极端的，通过单一架构将企业公共的能力包在一起，也是中台。