江苏龙网

  1. 首页 > 人文 > >

载风月|互联网中台思想和建设方法到传统企业为何水土不服？( 五 )


我始终任务：企业业务共性能力下沉 ， 并形成统一服务对前台提供 。
这样满足这个目标要求 ， 构建的就是企业中台 ， 这个中台是否一定微服务化反而不是重点 ， 只是说微服务化后 ， 整体的解耦 ， 扩展性更强而已 。
但是一定要注意到 ， 引入微服务本身对企业IT治理管控水平要求相对高 。 如果企业本身的IT成熟度没有达到一定阶段 ， 显然是不可能推行实施微服务架构的 。 这个道理前面已经谈到过 ， 在企业IT建设中 ， 如果连粗粒度的业务系统以及它们之间的集成都管理不好 ， 那么更没有能力管理细粒度的微服务模块 。
那么如果企业IT成熟度达到一定水平 ， 在推广微服务架构还存在的难点如下：
首先是架构设计能力的显性化 ， 即架构设计这个工作的输入 ， 输出和过程需要更加的显性化出来形成团队都认同的标准工件 。 一个业务系统没有拆分开时候 ， 虽然有架构设计和组件划分 ， 但是这个工作是属于团队内部的事情 ， 即使架构设计不合理 ， 在后期集成也可以通过诸多变通方式解决掉 。 而现在是不同的微服务模块可能分派到两个独立的团队开发 ， 原来属于自己内部黑盒的问题变为团队间问题 。
简单来说你原来藏着或没做规范的东西太多 ， 而现在这些不能再藏着掖着了 ， 当真要把这些东西拿出来的时候 ， 你才会发现你原来架构能力是有欠缺的 。 正如我们理解了一个东西 ， 那么要让我们清楚的讲出来困难 ， 那么我们的理解有欠缺 。 对于我们能讲清楚的东西 ， 要系统的写下来有困难 ， 那么说明我们讲的结构和条理有欠缺 。
其次管控要求和规范体系的建立 ， 对于管控要求可以看到如果两个微服务模块分给同一个团队开发 ， 如何才能保证开发的团队保持两个模块的完全独立和解耦 ， 两个模块间不会出现相互交叉的数据库直接调用 ， 也不会存在直接绕开Service接口的其它耦合调用？这些如果没有完整的管控和检查体系我们很难约束 。
微服务架构下导致的开发复杂度增加
载风月|互联网中台思想和建设方法到传统企业为何水土不服？只谈微服务架构的松耦合和高扩展性 ， 而不谈开发和集成复杂度的都是耍流氓 。
实际上当前很多企业对微服务架构并没有如此迫切 ， 互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力 ， 而实际大多数企业内应用往往并没有如此海量并发 。
其次 ， 即使在并发量增加的情况下通过进行代码本身的优化 ， 数据库调优或者升级硬件服务器资源都可以较好的解决性能问题 。 而做这些事情投入的成本远远小于微服务架构带来的开发复杂度增加成本 ， 后期的运维管控成本 。
要做到完全微服务模块独立 ， 微服务架构下最大的一个变化就是数据库也拆分开了 ， 原来的一个业务系统如果分为5个微服务模块 ， 那理论上就是5个独立的后台数据库 ， 而且数据库间还不能随便相互连接和访问 。 只有这样微服务模块才能做到独立部署和管理 。
由于数据库拆分带来两个问题 ， 其一是我们原来很简单的一个跨表查询操作现在无法做了 ， 我们必须调用两个微服务模块提供的服务 ， 查询到数据后再到逻辑层进行组合 。 其次最大的问题就是如果一个业务操作需要同时更新两个微服务模块的数据 ， 由于服务本身无状态 ， 导致了这种分布式事务问题很难解决 。
企业内业务系统很大一个特点就是业务逻辑和规则相对互联网更加复杂 ， 而且有更高的事务一致性要求 。 正是由于这个原因 ， 无法解决好分布式事务的问题都将直接导致后续数据不一致和业务错误 。
微服务架构下导致的集成复杂度增加
载风月|互联网中台思想和建设方法到传统企业为何水土不服？任何一个微服务模块在外部协同上都存在两个点 ， 一个是模块本身要消费和调用其它微服务模块提供的服务接口 ， 另外一个是模块本身又需要将其业务能力暴露为服务接口给其它微服务模块使用 。


推荐阅读


上一篇：黄河新闻网吕梁频道|张建康任晋城市中级人民法院代院长

下一篇：百变叨叨乐|外出打工人数排名第一，如今快沦落为空城了，中国最“拼”的城市