做互联网，企业信息化和IT系统建设，企业数字化转型相关工作的可能都知道，最近几年对于中台，微服务，云原生，消费互联和产业互联，DevOps和云原生解决方案等相当的火爆。

那么对于已经进行了传统方式信息化建设的企业，企业的CIO和信息化经理估计时刻都在思考类似遗留IT系统如何转型？如何应用这些新技术？使用这些新技术究竟能够带来多大价值等一系列的问题。颇有点当年不上ERP等死，上ERP找死的味道。

对于我自己从事企业信息化建设工作多年，特别是最近几年也接触了大量的企业IT部门，在经过这几年的外部项目建设，客户IT建设咨询相关问题沟通后，更加让我明确了对于大部分企业来说IT架构转型，新架构建设并非易事，盲目跟风往往更是带来后期大量IT管控治理问题。

业务目标驱动而非技术驱动

对于任何一个企业的信息化建设，简单来说就是业务目标驱动而非技术驱动。对于业务目标驱动我们又可以理解为在最高效的支撑业务目标的同时实现最好的投入产出比。

你所在企业的核心竞争力是什么？

任何一个企业核心竞争力一定来源于企业价值链分析模型中的核心价值链。可以是价值链中的一个流程，也可以是一个关键指标，而不是你的支撑过程能力。

核心竞争力可以是产品或服务可高度定制化，可以是性能指标最优，也可以是产品同样质量条件下价格更低，性价比更优。这些才是企业能够长期经营和持续发展的核心价值所在。

我们经常看到一个企业花很多钱，请国外的咨询公司做信息化规划咨询，虽然方法论很科学，模型和文档输出也很完善，里面可能还附加了很多业界标杆和最佳实践，但是企业很难按照这个去做，或者说按咨询建议做了也没有得到很好的效果。

那么实际问题在哪里呢？

我并不是说方法论不重要，而是大部分企业的信息化建设根本就没有到需要这么重的方法论来指导的地步，其次在当前信息化发展快速情况下没有任何一个咨询机构能够保证自己规划的东西5年后还适用，那么你去做5年后的规划有何意义？

因此很简单来说，在你理解了企业核心业务竞争力后，你刚开始的IT系统建设一定是围绕这些竞争力实现服务的，即使投入再大，建设复杂度再大你也要努力分阶段去建设和实现。

我们常说的信息系统建设决策中的复杂度，成本投入等指标全部不适用。比如你核心是产品质量和性能指标参数，那么你上MES系统优先级往往是最高的。虽然MES系统建设的难度，周期，复杂度都很大，但是你也必须迎难而上。

企业IT部门不能花点小钱上了OA或HR就沾沾自喜，虽然说上了OA对自动化和效率有帮助，但是对企业核心业务目标和竞争力提升没太大作用。

IT如何支撑核心业务能力？

对于IT系统如何支撑企业核心业务能力实现，简单来说就是当前的业务能够完全自动化支撑，业务流程连贯断点，业务数据一致无差错，业务系统易用速度快，业务数据能支撑持续改进。

从业务的视角可以看到，业务的述求里面从来就没有一条技术多先进，架构多灵活。

因此IT系统的建设和架构选型最终要以匹配业务目标出发，去选择在当前架构下最合适的架构方案。这个架构方案是性能和高可用，成本投入，可持续运维多方面的一个均衡。

大家要注意不是说架构可扩展性不重要，传统架构同样具备扩展能力，不是说你必须要上了中台和微服务架构才能够扩展。这些我们一定要有清晰的认识。

外购自主产品还是自主研发？

业务驱动里面强调了两个点，一个是业务价值实现，一个是IT投入产出最大化。

在我们考虑IT建设是外购还是自主研发，包括对于外购是按我们要求定制开发还是按供应商产品标准实现等问题的时候。核心需要考虑的就是在满足业务目标的时候如何实现最好性价比。

如何看IT投入性价比？

任何一个事情不能以短周期和静态的视角，而是应该以动态和长周期的视角。

拿IT系统建设举例，外购一个系统包括了前期产品购买+实施费用+后期运维费用；而自主研发则全面是人员投入费用。那你就需要用一个3到5年的周期去比较究竟哪个更划算。

IT系统建设说了这么多年，包括最近几年大量传统IT系统也逐步变化为SaaS服务模式，对于企业CIO来说要清楚的是你不要纠结你建设了数据中心，有套自己的软件系统，这些本身没有任何价值。

IT系统本身无价值，而是IT系统提供的IT服务能力产生价值，是IT服务在支撑了业务运作后遗留下来的数据本身有价值。

软件即服务，你需要的是服务，不是软件本身。

正是由于这个原因，对于大部分企业来说都是采购标准产品优于自己建设，采购云服务由于标准产品，当然这个选择的前提仍然是支撑业务目标要求的前提下。

对于现在企业内部的CIO或IT管理人员，我们看到一个奇怪的现象，就是啥技术热上啥，能够自研一定不购买成熟产品，把公司的IT团队搞得越来越大，招兵买马拉山头，技术也越来越复杂。这反而是一种极其不负责任的做法，即IT部门或管理者间接绑架了企业，企业确实离不开IT了，但是IT究竟为企业带来多大的业务价值，每年大量的IT投入究竟值得不值得说不清楚。

企业优秀CIO一定是对已有IT资源和成熟产品整合来支撑核心业务的能力。而不是去形成一个先进技术架构，核心技术研发团队的能力。

中台和微服务-从产生背景说起

对于中台概念，大家都比较清楚是阿里最早提出了大中台，小前台的说法。阿里巴巴 “大中台、小前台”机制的提出，某种程度上是从传统的事业部制向准事业部制的转换。

对于中台核心价值可以总结为关键的两点，第一点就是灵活敏捷支撑业务。

就阿里巴巴而言，“前台”就是贴近最终用户/商家的业务部门，包括零售电商、广告业务、云计算、物流以及其它创新业务等；而“中台”则是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。

前台和中台本质上是工作分工的问题。比如，某部门要开发一款App，是部门内部（大前台）自己组织一套技术、产品、设计、运营的团队，还是集团为其提供资源（大中台），由专门的技术团队来帮助其开发、设计产品等等。

所以说， “小前台，大中台”的运营模式，就是美军的“特种部队（小前台），航母舰群（大中台）”的组织结构方式，以促进管理更加扁平化。十几人甚至几人组成的特种部队在战场一线，可以根据实际情况迅速决策，并引导精准打击。而精准打击的导弹往往是从航母舰群上发射而出，后方会提供强大的侦察火力后勤支援。所以如果中台没有办法承接前线的需求，前线就会不认可它服务的价值。

第二点就是通过中台来实现进一步的资源整合复用，降低成本。

阿里巴巴近年来迅速扩张、员工众多，所以可能会存在管理不善、效率低下、各事业部各自为政等问题。为了解决以上问题，阿里提出了“大中台，小前台”机制。“小前台 大中台”的运营模式促使组织管理更加扁平化，使得管理更加高效，组织运作效率提高，业务更加敏捷灵活。

其“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子”的KPI项目。前台要做什么业务，需要什么资源可以直接同公共服务部要。

大家看到这两点，是否觉得跟传统企业内部信息化建设经常说到的SOA架构思想很类似。我们可以来看下SOA本身的定义，即：

SOA是一种架构方法，将传统的单片式应用打破，分解为离散的、自治的业务服务，利用标准提升他们的互操作性，从而可以更好地共享、重用和组装，快速构建复合的应用从而满足业务需求的变化。

在面对企业遗留IT系统架构的时候，SOA本身实际也是做两个重要的事情，其一是找到各个遗留系统共性的可复用的业务能力；其次就是在构建上层业务流程的时候通过服务组装和编排来完成。这个思想和中台思想完全一致。

只是大部分企业将SOA简单理解为了ESB和集成平台，更多用SOA去解决集成的问题，而忘记了SOA架构思想的本质仍然是共性业务能力下降，上层应用灵活编排。

再次说明，现在有个主流说法SOA已经过时，这个说法明显是不合理的，SOA仅是架构思想，这个架构思想不会过时，只是实现SOA架构里面的ESB可能逐步过时被API网关或ServiceMesh架构替代。

接着再来看下微服务，谈微服务一定是和单体应用对比。

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。

在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。

如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

我们可以先看下从单体应用到微服务架构的变化图。

从上面图里面我们可以清楚的看到单体转到微服务后带来的两个核心差异：

一个单体变多个微服务模块，而且从数据库到逻辑层到前端完全独立

微服务模块间通过Http Rest接口高效集成协同

谈到这里，我需要纠正下我原来的一个看法。

即SOA和微服务本质上不应该放在一个层面去比较，因为SOA里面强调的横向分层，可复用服务积累，上层服务灵活组装形成应用几个关键点在微服务里面都没有。微服务仅仅是模块间接口交互走了轻量的Http Rest接口而已。

微服务简单来说强调的是纵向大单体拆分小，因此更多应该和单体应用做对比。

题外话：经常看到有人将业务逻辑层理解为中台，这个也是错误对比，这两个不是一个层面的概念。中台模块有业务逻辑层，前台模块也有。要明白不是所有业务逻辑都是共性和可复用的，对于不可复用的业务逻辑仍然是在前台模块中，而非中台。

互联网和传统企业差异

对于中台和微服务，我们看到互联网企业建设案例特别多，在互联网企业取得成功后很多传统企业希望按照互联网企业的做法来实施中台和微服务，那么我们就来看下实际的一些区别点。

IT本身就是互联网企业核心竞争力

前面我已经谈到，任何企业都要先分析其核心竞争力。

那么对于一个建设和运营电商平台的互联网企业，它的核心企业本身就是这个电商平台应用，而且你也可以看到研发，运维，运营等大量人力资源全部集中在这个平台上。也就是说你看到的互联网企业80%乃至更高的成本投入全部在IT建设和IT人员上面。

互联网企业的IT系统或运营的APP就是其核心竞争力。

在这种情况下，互联网企业舍得在IT上投入，因为这个投入本身就是提升核心竞争力的，其次舍得招人自主研发，即IT系统的能力必须要牢牢的控制在自己身上，形成自己核心资产。

对于传统企业来说，虽然IT也很重要，但是很少会说IT能力是企业核心竞争力。包括我们看到很多营收上10亿的传统企业一年不到100万的IT建设投入都是常事。

所以从这点上来说，任何传统企业都不可能投入大量成本来搞IT新技术。

传统企业IT是否面对互联网一样的高可用需求？

对于互联网企业，为何对架构的性能，稳定性，扩展性等如此重视。简单来说同样也是运营的业务驱动。一个互联网企业运营的平台宕机10分钟往往都是致命的，包括类似双11，秒杀等各种活动，你必须要有高性能，高可靠和可扩展的架构来支撑。

否则流失的就是最终用户和流量，最终影响到企业的运营和收益。

传统企业的内部IT，即使并发量再大，很少有需要达到互联网这种大并发量的需求；即使高可靠性要求再高，也很少说需要做到完全没有停机运维时间。

杀鸡焉用牛刀，而很多传统企业往往搞得就是老想着用新架构和新技术来解决手里面的问题，而不是想着如何把自己手里面的菜单磨得更快。

3年左右扩展需求是必须考虑，什么为5到10年扩展需求考虑就是扯蛋。

再来理解传统架构到中台微服务的变化点

前面介绍了中台和微服务的基本思想。

可以看到对于传统架构转型过程中，刚好就是中台和微服务两者思想的一个融合过程。中台强调的是横向分层和能力共享，而微服务强调的单体纵向拆分更细。如下图：

在谈中台的时候更多的是业务层面用词，而谈微服务的时候更多是技术层面用词。在谈中台的时候你首先考虑的是业务模块如何划分，服务如何识别，而实现技术是微服务。而谈微服务的时候本身就是技术实现和架构方法，是否一定用于中台倒不是必须。

因此要回答两者区别这个问题，我们首先还是要看下中台和微服务这两个概念是针对什么来说的。

中台：说中台一定会说到前台，原来是中台前台不分，现在是拆分为中台和前台。

微服务：说微服务一定说单体应用，原来应用粒度太大，要垂直拆为更小的微服务。

这个搞清楚后，我们就更加容易理解两个概念的区别，即：

中台更多的是指横向拆分，即共性业务能力的下沉，然后再将服务能力开放给前台应用使用。而微服务更多是技术用词和软件架构开发方法，强调的是大单体要拆分和进一步解耦。

而我们现在构建企业中台，基本是中台和微服务都会使用到，即既需要进行横向拆分，共性能力下沉。同时对于下沉的共性能力又需要按微服务思想进一步拆分多个微服务模块。在中台思想里面更加强调了共性能力下沉和能力开放，能力开放以微服务里面常见的轻量API接口方式进行。

了解了这个我们看区别就比较清楚了，具体如下：

中台强调横向拆分和分层，微服务强调纵向拆分和解耦。

中台建设的目标更多的是下沉共性能力，识别和暴露可复用的API能力接口，供前台应用快速开发和组合，这才是中台构建的目的。而对于微服务来说，更多强调的是单体应用进一步的拆分和解耦，并通过轻量API接口高效协同，只要满足这个要求本身就是微服务思想实现。

中台的构建不一定要采用微服务，也可以采用传统IT架构进行构建，只要满足共性业务能力下沉要求即可。类似我们传统架构里面的MDM主数据系统，按现在微服务思想应该拆分多个服务，但是即使没拆，我们仍然可以理解为是企业中台建设思路。

再次强调中台和微服务区别的一个原因就是。

当企业重点是在构建可复用的业务中台能力的时候，你完全不必一定按互联网做法将中台拆分为多个微服务，即使没有拆分，只要你识别了共性可复用的业务服务，并统一暴露给上层业务使用，那么就可以理解为企业进行了中台建设。

比如企业已经建设了ERP，CRM，PLM，SCM等多个业务系统。现在将各个业务系统共性业务服务能力识别出来，并开发后注册接入到ESB平台形成统一服务能力开放。在企业构建新的报账业务的时候刚好可以复用这些已有能力，那么这个共性能力积累就可以看作是企业中台。

新架构引入应以问题和风险驱动

在我们谈IT架构转型的时候，一定要从实际的场景和问题去分析，不是为了新架构而架构，这个也是我一直强调的重要观点。而对于问题本身我们又要理解到实际上包括了两点。

当前已经面临的问题：类似系统性能问题，运维问题，安全问题等。

已经发现趋势的风险：根据历史数据趋势已经发现关键风险。

当前已经面临的问题

对于一个传统的IT应用架构，我们可以来看下可能存在的当前面临的问题，这些问题既包括了业务层面，也包括技术层面，还包括了管控治理层面。但是最终都可以归集为对于IT系统支撑业务需求和业务目标的能力变弱，或者说已经到了无法支撑的程度。

其一，老技术框架已经无技术支持

一个IT系统的开发一定会涉及到相关的技术架构选择，包括了技术平台，开发框架，开发语言，开源组件使用等，而这些平台或框架随着时间推移本身也在不断升级，还有些干脆就是不再提供技术支持。这些都需要我们对已有的IT系统进行全新改造或升级。

类似我们原来用VC++开发的业务系统，到了11年都还在用，但是微软已经不提供支持，只能够逐步将功能移出。还有就是开发框架和语言，数据库的版本在不断升级，旧版本不再提供支持，这些也需要我们定期对业务系统进行版本升级改造。

其二：应用以及无法再进行扩展

传统IT系统是单体应用，虽然单体应用本身可以集群化部署，但是很多时候对于数据库往往并不会使用RAC集群，或者说数据库本身并没有扩展能力。这个在业务系统发展到后期，在用户数，业务数据量，并发量都不断增加的情况，带来的明显问题就是性能问题。

而这个性能问题也是业务系统不断持续优化的关键，包括了数据库集群化升级改造，历史数据清理和迁移，本身的SQL语句和代码优化等各种方式，最终都是为解决性能问题。当以上各种方式和努力都不太起作用的时候，往往就涉及到真正开始将单体应用进行逐步拆分和剥离。

其三，IT系统的可运维能力下降了

发现问题或故障的时候查找原因很难，可能大半天都定位不了具体的问题究竟出在哪？其次就是系统原始架构就部署完全冗余化设计，导致出现问题后的系统恢复时间也变慢了，有时候即使重启整个应用也无法恢复，这些都将直接影响到具体的用户使用和需求满足。

其四，单体系统模块紧耦合导致敏捷响应业务需求的能力变慢了

用户提交的需求变更往往要花很久的时间才能够变更完成并最终上线发布。其原因就是整个单体系统随着后续功能的叠加变得越来越复杂，模块间的耦合性也是越来越强，即使最简单的一个变更可能都涉及到代码多处的改动，而且代码和代码之间还有千丝万缕关系，稍不注意就可能影响到其它能够正常使用的代码。还有些应用模块间的集成还不是走的标准的应用层API接口，而是直接使用的数据库Dblink连接，这个更加导致了一个数据库究竟有多少外围在使用，究竟使用了哪些数据库表完全不清楚，任何一个数据库的表结构变更往往都影响巨大。

已经发现趋势的风险

什么叫已经发现趋势的风险，简单来说就是随着用户数，业务量和并发量的增长，你已经能够明显感觉到系统在变慢，但是还能够忍受，你预估和测算这个趋势会发现到了哪个时间节点可能IT系统的能力就无法满足。那么你就必须提前去考虑这个问题，并对相关的架构和技术点进行优化改进，而不是眼睁睁的看着问题变化为风险。

其一，系统可扩展性能力弱是最容易发现的风险

即随时业务量增长你发现系统没办法做到完全的平滑扩展，这里面包括了数据库，也可能包括了应用服务器集群，你会发现由于没办法做到扩展，等数据量和并发量一上来一定会出现应用性能问题和瓶颈，这个时候你就要早点去考虑架构优化和升级。这个升级一样两个方式，一种是已有架构优化支持扩展性，一种就是彻底的微服务化拆分。

其二，IT运维能力无法有效支撑风险

就是前面说过的可运维能力变弱，IT系统上线了，但是你发现对IT系统的运维和监控能力没有跟上，导致出现问题后查找和定位故障相对的耗费时间。那么这种时候一定要考虑对系统进行优化，这个优化不仅仅是包括了实施相应的IT监控和APM系统，更加重要的是对已有的系统代码进行优化，包括了相应的日志记录，日志采集，性能数据收集等，关键异常日志记录等，这些都是方便你后续快速的定位故障和问题。

系统变得没法维护了，也是我们经常会遇到的问题，代码间耦合性强，而且逻辑混乱，修改代码的时候往往摸不着头脑，相关的变更也是到处乱加，到了这个时候一定要考虑对代码进行优化和重构，理清代码逻辑。所有开发人员都要意识到代码的可维护性是代码的一个关键非质量属性。

传统架构转型必须思考三个层面内容

要说到传统企业IT架构转型，我们可以看到很多关键词。

中台，数据中台，数字化，微服务，SOA，服务识别，API网关，DevOps，敏捷开发，持续集成，PaaS平台和容器技术，中台规划，监控，运维，自动化测试，研发项目管理，过程改进，Spring Cloud框架，流水线编排等。

但是不论涉及到多少的技术和关键词，我们可以看到传统企业的IT架构转型实际上核心就三点。分别是业务层，技术层面和管理层面。

业务层面：核心能力中台构建，也可以说是微服务模块的划分和API接口服务识别

技术层面：核心是云原生，包括微服务+DevOps+容器云

管理层面：研发管理过程的改进和管控治理体系建设

其一，在业务层面重点是中台建设规划和服务识别

中台建设的核心是基于企业架构+SOA融合思想，以业务驱动IT，从端到端业务流程出发，为企业梳理完整的业务架构，数据架构，应用架构和技术架构，而整套企业架构规划的方法也完全适用于粒度更细的微服务模块划分，中台规划建设。

当然新的中台构建咨询规划对传统企业架构也进行了大量裁剪和改进，在后面我会专门写文章来进行说明，特别是在核心的模块拆分和服务识别上面。

其二，在技术层面重点是云原生解决方案

对于Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。

云原生应用程序开发通常包括DevOps，敏捷方法，微服务，云平台，Kubernetes和Docker等容器，以及持续交付，简而言之，每种新的和现代的应用程序部署方法。

微服务架构+容器化+DevOps 将成为后续企业信息化转型的主流趋势。而这三点刚好也是云原生解决方案中最重要的内容。

简单来说，一个企业实施微服务看着简单，但是微服务一上来，原来的10个系统变成了100个模块，这么多模块如何部署集成，如何管理，如何后期运维，这些都需要类似DevOps支撑和容器云等一系列的技术相互配合才能够完成。

其三，全面提升IT管控治理水平

这个就不展开讲了，即新技术的实施你的管控治理能力也得跟上。从最早的软件工程和研发过程管理，CMMI,到新架构下的敏捷方法论和持续集成等，这些都需要企业的IT部门逐步形成完整的，成熟的标准规范体系，并付诸于实践。

包括我们当前看到的DevOps，也以及形成了完整的能力成熟度模型供实施企业参考。

因此对于一个企业，当你自身能力不足的时候务必谨慎对待微服务的引入。最后一个部分我想再次对这点做下详细说明。

企业要谨慎对待微服务架构

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

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

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

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

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

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

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

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

企业自有开发团队实施微服务

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

那么如果企业IT成熟度达到一定水平，在推广微服务架构还存在的难点如下：

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

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

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

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

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

实际上当前很多企业对微服务架构并没有如此迫切，互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力，而实际大多数企业内应用往往并没有如此海量并发。

其次，即使在并发量增加的情况下通过进行代码本身的优化，数据库调优或者升级硬件服务器资源都可以较好的解决性能问题。而做这些事情投入的成本远远小于微服务架构带来的开发复杂度增加成本，后期的运维管控成本。

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

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

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

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

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

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

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

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

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

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

正是由于这个原因，我们要求在一个大体系里面，每个微服务模块的开发质量都要得到保证，这已经不是单个模块自己的事情，而是直接影响到大系统的质量。

微服务架构下的运维问题

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

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

再次，如果发现了性能问题或故障，我们的解决方案是如何的？

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