文章带有强烈的个人观点和成长经历，针对的是政务项目，而非互联网，参考即可。

背景介绍

一直网上查找相关的学习资料用于实践并落地服务化，分布式，美好的资料与真正落地实践是两个一样的层次，真正能落地的资料较少，这过程中有很多的问题，能不能解决，团队、个人能不能支撑这个过程，都是一个问号。其中很多讨论的就是Dubbo和Cloud的选型的问题，这里表达一下自己的实践经验的感受与选型，我有我思。

微服务是一种架构设计，但是我这里说的更多的是服务化，主要针对的是传统项目转过来的过程，所以，以下文以服务化来代替微服务。此处针对的是政务型项目，而非互联网项目，自己在政务项目经验较多，而互联网项目项目经验、管理经验较为缺乏，比如团队管理政务项目更偏向于人才培养，技术积累，可以使用信息化项目管理体系管理项目，但是互联网项目可能有些并没有这个条件，比如一个项目周期2至4个星期，项目管理体系还没有起来就可能结束了。

为什么拥抱Dubbo而排斥Cloud体系，并不是因为技术不好，也不是因为技术过分崇拜，更不是因为国内外，或者阿里系，Spring系之类的，而是自己在建立个人学习开发平台的过程中，

自己的经验和体会表达，原开始使用的是Cloud技术，后来转变成Dubbo技术，这一过程中的体会，分以下几个点阐述：

团队和人才市场有一定的局限

从大一点的来说，Java的工程师培养一直以来都是SSH或者SSM体系入门，同时MVC层次更是深入Java开发人员思维，这些几乎是每个Java都是非常熟悉，接触的项目最多架构。大量的培训机构，都是这几套，几乎是这10多年Java软件培育的结果，这为在后期招聘，运维，团队组件上规避了极大的招聘风险，团队风险。

从小的来说，目前接触的团队，几乎都是单体项目转过来，开发过程，不管是异常处理，问题处理，都有极大的经验值，还有习惯，思维，这些都有极大的促进项目的开发效率，而这些都是建立在【习惯】的思维上，在服务化的路线上，如果选型得当，几乎可以省去很多的培养成本，适应成本。

这点不能站在开发者的角度，常常听开发者说这个技术没问题，但是团队来说，团队的角度考虑，服务化一个人开发跟一群人开发是天与地的区别

怎么使用旧的资源，更低成本的实现服务化，服务化之后是否能提高研发效率，解决业务问题，解决项目管理问题，解决团队开发效率问题，怎么引入新的技术，怎么引入DevOps，又要团队能接受，成本能接受，同时又要降低抵触情绪等，才是需要思考的，相对而言，技术点就比较容易考虑了。

回到我们的技术点上，我们来看一个技术例子，Dubbo技术几乎是无缝切入MVC工程，或者SSM工程，这几乎是归功于Dubbo的传输方式，相对而言，Cloud的HTTP+JSON传输，在这过程工程之间的交互几乎是灾难，复杂的数据不能传输，传输效率过低，接口管理困难，而在Dubbo这块，利用JavaAPI的特点，接口调整便直接提示异常，一目了然（也有弊端，这靠规范来管理），也规避了这部分风险，省去成本较高的接口管理（并不是不需要管理，更多的建议是规范）。

在之前实践的过程中，这步做得倒还是比较成功，技术上遮蔽了注册这块（即这些都已经配置好），前期融合的Java工程，Dubbo技术还是比较容易，有些项目组成员开发了近半年，依然感觉在做单体应用，甚至没有体会到这个是在分布式应用或者微服务。更有甚的，服务化项目已经准备上线了，有开发拿着一篇PPT说，”你看这样的技术架构，我们是不是也考虑一下“，而他说的那个PPT的架构，已经是两年前做的设计，并且实践成功落地。

业务场景限制和资源限制

业务场景是设计人员必须要做的考虑，团队不管是技术能力强还是资源充足也好，但是结果是否能实际的完成业务开发，服务于业务这才是价值体现。业务场景有哪些？

需要考虑怎么样的场景，这需要针对具体的业务实现，而往往针对于企业来说，至少软件公司来说，同步也要考虑实际团队的场景，能力，能产生的价值，而不是团队都是初级工程师，偏偏要规划出高级产品设计，更不要项目周期短，却规划出一个N多组件的微服务项目，服务组件全套用上。项目开发最终的目标不是为了微服务那套治理，更不是那整套的监控，也是不是那一个个组件，更多的为了业务服务，为了提供更高的生产力，本质是产生价值。

项目经费，周期，团队，硬件等资源限制，怎么能更好的在有限的场景里面服务好业务，又能落地好技术的规划，服务化组件的抽取，共用，同时还要能完成指定的指标，这是需要考虑的。

Cloud研发过程太多的组件和概念，相对来说，可能【完善】，但是反面来，却可能成了开发的壁垒，毕竟，不是每个项目都是一上来就有十几或者上百台服务器的资源，几千万的项目经费，更多的可能是几百万，几十万，只提供几台16G内存，硬盘暂时考虑都满足，一个Oracle或者MySQL数据资源。 整个服务化过程中，项目只需要一个稳定的，功能完善的RPC服务，来完成SOA，需要治理，也需要监控，但是这个并不是必须， 需要的是完成项目，快速研发并提供服务，消费服务。

而正是Dubbo精简化，针对性，有监控（Dubbo-Admin）等的情况下，服务化项目考虑，经过多年国内实践，有大量现成的文档和解决方案，满足实践项目开发的需求，反面变成轻量级的服务化工具，更加合适团队，一个问题，你确定你的项目真的一定需要分布式配置中心么？

技术过分冗余，软件价值考虑

所谓的冗余，有点类似于鸡肋的说法，丢了又觉得可惜，使用又觉得用不上，或者使用的场景很少之类的，刚刚上文也提到，分布式配置中心是否真的工程需要的（安装一个Apollo需要多少服务器资源？）；再比如是否真的需要链接跟踪，业务真的有那么大的访问量，再或者这访问过程是否是可能通过日志手段排查；再比如ELK，还有容器化，消息中间件之类的。以下的场景针对于一般性项目（几十万至几百万政务系统）来说，相信这类型项目在政务来说，比较常见，而这类型项目的服务器资源，项目资源（硬件，软件）往往很少 。

上面提到的，只是一部分，听起来好像有点不太可思议，甚至有点冲动，

“分布式项目怎么不需要配置中心，不是更简便的么？” “ 消息中间件是来处理日志或者可靠消息，必不可少的“”容器化容易发布“ 或者说 ”ELK可以有界面查询，及时收集多台服务器的日志” 等等

这些都没有错，但是也要考虑一点，但太多的技术债，维护成本有可能远高于应用系统的维护成本，原本应用软件就一个运维可以搞定的，加上这些不知名（相对于原运维来说），处理起来更加困难，而往往要求助于开发，这样，一个运维的成本，还有开发人员的支持，运维的成长周期可能就需要1至2年，而一个软件项目的生命周期也仅仅是5~10年（再往上的，稳定性也已经很强）。而实际上，这类型的项目实际在测试过之后，稳定性及可靠性已经很强，出现问题的往往并不是技术问题，而是业务问题。

即使出了线上问题，排查周期一年左右，基本上也趋于平稳，而使用大量的技术冗余，是否确定可以这一年里面运维可以正常学习到？或者再反问，确定运维会去学么？开发人员的支持一定到位么？中间沟通成本是否有考虑过？学习成本与问题消化成本是否等价？

技术精简化，遮蔽技术，大道至简等这些都是设计中需要考虑的，而Cloud大量的技术引入，是否真的合适这样的场景，是否让团队可以正常消化，并产生价值，这是我们需要考虑的。没错，传统软件开发确实很困难，有弊端，DevOps体系，服务化架构确实可以做到一定的提升，但是我们怎么最少成本切入，并提升我们自己的价值，这不是更重要？也许刚刚上面提到的，人员培养过程确实为后期提供了另一种可能，也是企业所需要考虑的，但是有一定是成本权衡。

相对而言，Dubbo这块的稳定性，效率，精简，与Spring的无缝融合，相对于Cloud的大量的技术债，确实有它一定的优越性，灵活性。

更灵活的技术迭代和选型

项目架构的设计，项目的版本提升，迭代，新技术怎么快速切入原项目架构而不影响，甚至是替代，都是需要考虑的。这不是必须，也可能不会发生，或者发生的机率比较小，但是它确确实实存在。

一般的项目上线，可能在这个周期内不会变动，但服务化的产生，使得大量的组件产生和成熟，在新的项目中产生迭代，升级，而这一些的操作过程，都是尽量原子化，比如替换掉UI，可能一次性替换，比如升级Dubbo，，升级Spring，怎么样快速做到灵活升级，而且对开发人员做到无感无知（理想状态），更或者产是不影响当前的版本，这是我们需要考虑的。

再回到Cloud，组件封装得甚至有些过渡，我们团队，也可以说你们团队确定是可以接受它技术的迭代么？1.5到2的升级，就有了很多变动，甚至要调整业务代码。为什么？Spring团队并不是针对于一个技术团队服务的，而是针对于所有的Spring开发者。如果我们自己不能把控，即使能把控，也有可能会产生大量的维护成本，人员成本。组件太多，甚至你也不知道他在哪里，而某个依赖的升级，是否会影响到其它版本的正常运维，这更难说。

怎么样有效管理工程迭代，升级，做到对开发的无缝感知，这是我们需要考虑的。

这里就不再细说，Dubbo就只是一个包，换掉即可，其实个人建议是不要换，因为这个包只是为我们提供了高质量的RPC服务，稳定即可，更多的，推荐升级周边服务，比如MyBaties，Spring等。一些场景下可能是一定要做升级的，比如兼容K8S，目前Dubbo转Apache维护，升级官方也出了文档，Cloud升级是否可能提供文档，也许可能，但是太多组件，风险也很大。针对于Dubbo工程，依赖包的问题会产生未知包引入，这个我们是在行政管理和代码评审上做的强制管理，这些由规范做约束。

推荐服务化技术实现方式

与其说推荐，更多说的是实践过程中积累的实际场景，学会取长补短，两者结合，也未偿不可。大概画了一个简单的架构设计图，对内使用Dubbo的优势，对外使用Cloud的概念。

服务化技术架构，Cloud有一定的优势，但是我们需要用到的是他的是HTTP+JSON，而这个，Boot已经实现了，与其说使用Cloud，还不如用Boot，可以适当引用一些Cloud组件，比如网关组件，消息组件，分布式链路跟踪组件，熔断器组件（不过听说不维护了），做为外部系统对接，如第三方系统，或者内部多系统对接。对内采用Dubbo提升开发效率和传输效率。

技术本身没有对比性，只能说场景符合，针对合适的场景，团队，项目，条件等使用合适的技术实现。