【转载】企业应谨慎对待微服务架构（2）

原文地址：http://blog.sina.com.cn/s/blog_493a84550102wkc8.html

下面实际谈谈引入微服务架构的难点，以下谈到的都是企业引入和实施微服务架构可能遇到的困难和阻力点，而实际实施难度可能远高于我下面的描述。

引入的软件开发商本身的水平和意愿

如果一个企业本身IT部门规模小，软件以外购为主，那么势必在对ERP等各类软件的选型评估后引入不同的软件产品提供商或软件开发商。那么软件商本身都有了成熟的产品或架构，其产品内部的模块是否符合组件化和微服务架构的要求，我们不得而知。

即使招标要求写明软件提供商提供产品需要基于SOA或微服务参考架构，但是实际上由于企业本身的IT能力和水平往往也无法验证，而对于软件厂商来说一定希望是卖现有产品，减少改造和定制实现利润的最大化。

对于软件开发厂商来说对已有的软件产品是没有微服务架构改造的动力的。那在这种情况下要推动微服务架构实施落地必须的就是企业本身有很强的架构管控能力和甲方话语权。

在曾经实施的案例里面可以看到，甲方在有较强的IT规划和架构设计能力情况下，才可能一开始就划分好微服务模块并且设计好微服务模块间的接口，在进行招标和选型。同时甲方话语权强的情况下，可以完全要求软件供应商按照自己定义好的标准，规范，架构进行微服务模块的开发。

简单点来说顶层架构分解和接口设计能力不在单个微服务模块开发商手里面，而是在甲方手里，或者在甲方请的专门负责规划架构设计的技术咨询团队手里。

在这种模式下，技术咨询团队应该对整体模块划分和后续集成负责，技术咨询团队就需要有业务和技术两方面的能力，同时有类似领域的规划设计经验，系统开发建设经验等。这些本身就对技术咨询团队提出了相当高的要求，可以来讲很少有技术咨询团队达到这个水平，包括埃森哲或德勤等也难。

在微服务架构下，我们希望的是一个业务系统如果由三个微服务模块组成，在我们进行了前期的架构和接口设计后，我们完全可以将三个模块发标给不同的软件开发商建设和实施，然后在根据预先定义的服务接口进行集成。这个从理论上是行得通的，但是实际上出现两个问题。

其一是刚开始的模块划分或接口设计不合理，在后面开发过程中才发现又很难再大变更。
其二是微服务模块间的接口服务太多，导致了模块间的集成和联调异常复杂。

从上面也看到引入微服务架构后，企业本身可以削弱单个软件供应商对企业本身的约束，防止被单一厂商绑定。因此企业没有特色要求，从软件厂商来说没有任何动力和意愿推微服务架构。

企业自由开发团队实践微服务架构

如果企业本身的IT成熟度没有达到一定阶段，显然是不可能推行实施微服务架构的。这个道理前面已经谈到过，在企业IT建设中，如果连粗粒度的业务系统以及它们之间的集成都管理不好，那么更没有能力管理细粒度的微服务模块。那么如果企业IT成熟度达到一定水平，在推广微服务架构还存在的难点如下：

首先是架构设计能力的显性化，即架构设计这个工作的输入，输出和过程需要更加的显性化出来形成团队都认同的标准工件。一个业务系统没有拆分开时候，虽然有架构设计和组件划分，但是这个工作是属于团队内部的事情，即使架构设计不合理，在后期集成也可以通过诸多变通方式解决掉。而现在是不同的微服务模块可能分派到两个独立的团队开发，原来属于自己内部黑盒的问题变为团队间问题。

简单来说你原来藏着或没做规范的东西太多，而现在这些不能再藏着掖着了，当真要把这些东西拿出来的时候，你才会发现你原来架构能力是有欠缺的。正如我们理解了一个东西，那么要让我们清楚的讲出来困难，那么我们的理解有欠缺。对于我们能讲清楚的东西，要系统的写下来有困难，那么说明我们讲的结构和条理有欠缺。

其次管控要求和规范体系的建立，对于管控要求可以看到如果两个微服务模块分给同一个团队开发，如何才能保证开发的团队保持两个模块的完全独立和解耦，两个模块间不会出现相互交叉的数据库直接调用，也不会存在直接绕开Service接口的其它耦合调用？这些如果没有完整的管控和检查体系我们很难约束。

微服务架构下导致的开发复杂度增加

只谈微服务架构的松耦合和高扩展性，而不谈开发和集成复杂度的都是耍流氓。

实际上当前很多企业对微服务架构并没有如此迫切，互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力，而实际大多数企业内应用往往并没有如此海量并发。其次，即使在并发量增加的情况下通过进行代码本身的优化，数据库调优或者升级硬件服务器资源都可以较好的解决性能问题。而做这些事情投入的成本远远小于微服务架构带来的开发复杂度增加成本，后期的运维管控成本。

要做到完全微服务模块独立，微服务架构下最大的一个变化就是数据库也拆分开了，原来的一个业务系统如果分为5个微服务模块，那理论上就是5个独立的后台数据库，而且数据库间还不能随便相互连接和访问。只有这样微服务模块才能做到独立部署和管理。

由于数据库拆分带来两个问题，其一是我们原来很简单的一个跨表查询操作现在无法做了，我们必须调用两个微服务模块提供的服务，查询到数据后再到逻辑层进行组合。其次最大的问题就是如果一个业务操作需要同时更新两个微服务模块的数据，由于服务本身无状态，导致了这种分布式事务问题很难解决。

企业内业务系统很大一个特点就是业务逻辑和规则相对互联网更加复杂，而且有更高的事务一致性要求。正是由于这个原因，无法解决好分布式事务的问题都将直接导致后续数据不一致和业务错误。

原来通过调用项目内一个API方法就能解决的问题，现在要调用远程WS接口才能解决，这本身就增加了开发和调试的复杂度。一个微服务模块与外部其它模块的集成和协同越少，你会发现该微服务模块和传统业务系统开发没太大区别，但是当其涉及到完成任何一个功能都需要调用外部微服务模块的服务接口时候，其开发模式和效率上就会带来巨大的变化。

微服务架构下导致的集成复杂度增加

任何一个微服务模块在外部协同上都存在两个点，一个是模块本身要消费和调用其它微服务模块提供的服务接口，另外一个是模块本身又需要将其业务能力暴露为服务接口给其它微服务模块使用。

如果一个微服务模块要同时支撑PC端和APP端，可以看到微服务模块暴露的服务还需要统一提供给前端的展示用。那么可以看到一个微服务模块需要完成自身组件层和展现层间的集成，同时又需要完成多个微服务模块组件间的横向服务集成。

如果我们将消息，日志，流程，4A等能力下层到平台层微服务模块，那么一个组件要跑起来还涉及到和平台层的多个技术类微服务模块集成。在如此复杂的集成场景下，要将复杂的跨多个微服务模块的横向端到端业务跑通，其涉及到的模块数，接口数都远超原有单一系统的模式。

一个业务系统如果没有拆分为微服务模块，那么其它内的模块间集成和集成测试是系统内部的事情，但是一旦拆分为多个微服务模块，那么这种集成就变成外部第三方的事情，或者必须要显性的事情。

对于一个微服务模块来说，当其需要集成的外部微服务模块和接口都变多的时候带来什么问题呢？这个问题大家容易理解，即该模块究竟是否稳定已经不是模块本身的事情了，而是涉及到诸多外部依赖模块是否稳定。更简单说本来原来我自己可以确认稳定的事情，现在我无法确认了。即使每个模块的稳定度都90%，但是你会发现一集成起来90%*90%*90%，那么稳定性就下降的很厉害。正是由于这个原因，我们要求在一个大体系里面，每个微服务模块的开发质量都要得到保证，这已经不是单个模块自己的事情，而是直接影响到大系统的质量。

是否要实施和Docker集成的问题

实际上，一个企业开始实施微服务架构，并不一定马上要和docker集成，毕竟企业内部的的业务系统并发量和性能拓展不需要做到完全的自动化。先把组件化和服务化做好，确保各个微服务模块是可拆分的，等真正实施上去了再来考虑如何自动化部署和动态扩展的问题。

微服务架构下的运维问题

在实施了微服务架构后，运维的复杂度也是成倍增加，任何一个微服务模块出问题都可能影响到整个业务应用的功能使用。我们在运维时候不仅仅要健康单个微服务模块，还需要健康所有的接口服务监控状态。

如果跟Docker集成了，我们看到整个性能监控和问题分析都会变麻烦了，没有实施微服务架构前发现问题，我们直接可以看应用服务器上类似tomcat或jboss日志，而实施了微服务架构后，应用容器已经是自动部署和动态分配的，原有的故障诊断模式行不通，而需要PaaS平台本身提供完整的预警和日志分析能力。

再次，如果发现了性能问题或故障，我们的解决方案是如何的？我们如何保证不影响到业务运行，不出现数据的丢失，或者在微服务模块扩展的时候不出现业务中断等。这些已经不是简单的部署架构层面的冗余能解决的问题，而涉及到我们在整个微服务架构中的消息策略，事务管理机制，持久化机制等问题。