对于传统企业IT架构的改造，中台与微服务架构规划在我头条上一篇文章中进行了系统的梳理和讲解。2020年就提出来了，但是2020年可以算是云原生的元年。同时，企业IT架构转型、微服务化、逐步向公有云迁移也将是未来多年的技术发展趋势。近期，我们结合合作伙伴和客户，对一些常见问题进行了梳理和说明。中台和微服务规划其实可以理解为传统企业架构和信息化中台规划的子集，传统SOA架构规划。其核心是业务驱动的IT，基于业务流程和业务对象分析识别核心可重用的业务组件和能力。降低通用业务能力，提供粗粒度的接口供上层使用。中台本身是一个商业概念，而不是一个技术概念。能够做中期规划的，不是新兴的咨询公司或技术过硬的软件服务商，而是扎根于某个垂直业务领域的传统传统咨询公司或软件服务商。即对垂直行业的业务理解深度和传统的咨询策划能力远远超过技术能力。一个新兴公司为各地的客户规划中期是不合适的。没有业务领域的沉淀，你如何给别人规划中期，如何识别可复用的业务能力。如果没有业务积累和沉淀，再好的方法论也无法在实践中指导你。虽然我在文章中整理了中国大陆和台湾的规划方法论，但实际上我不能在我不熟悉的业务领域为别人做规划。熟悉一个技术架构思路可能需要一周时间，但熟悉一个垂直行业至少需要一年甚至更长时间。所以做技术策划相对容易，做业务和中期策划就比较难了。难点不在方法论上，而在业务积累和沉淀上。微服务——不要把标准硬性化其实我们在改造微服务架构，包括和客户讨论微服务，往往有两个极端。一种情况是大型应用的应用层拆分了，但是数据库还是一个；另一种情况是拆分微服务和数据库严格1:1。对于第一种情况，由于DB没有拆分，所以实际上还是一个紧耦合的系统。第二种情况，微服务的拆分导致大量独立的细粒度数据库实例，进而带来大量的分布式事务问题。其实更好的做法应该是根据企业业务域的情况进行折衷，将数据库按照业务子域进行拆分，业务子域内部的应用层也可以拆分成多个微服务。包括在微服务的实现上，经常有人说你的架构前后端不分离，不是微服务。事实上，前后端分离并不是微服务的必要条件。比如有些客户在实现微服务的时候，虽然前后端分离，但是后端提供的API接口服务都是细粒度的，同时是1:1的用前端方法。、服务复用等关键特性，反而增加了前后端协同联调的复杂度，这样的分离是没有意义的。DevOps首先是流程，其次是DevOps的工具集成，虽然我之前的文章也详细介绍了目前我们规划开发的DevOps支撑平台。但是大家还是要认识到，DevOps首先是流程的改进和优化，其次是工具集成和自动化。比如我们看到一些企业已经实现了CI/CD集成、流程自动化等，但是你会发现从用户需求收集到版本规划，再到最后的开发实施上线，整个流程管理还是很不规范的。乱，还是需要工具。、研发、测试人员之间有大量的人工沟通和协作。那么DevOps实施的意义何在？所以，对于DevOps来说，首先是敏捷和持续集成交付过程的改进，其次是使用什么工具和技术。技术往往难以推断流程优化和改进。流程改进需要组织、团队和文化的改进。可以看出，从大数据平台到数据中台，很多现在做数据中台的服务商其实都是原来做大数据平台的服务商。那么大数据平台和数据中心有什么区别呢？对于一个大数据平台，你可以理解为一个纯数据技术的能力平台，它本身是空的。就像我们理解ESB总线一样，它本身就是一个技术平台。一开始，上面没有注册接口服务。需要自己不断接入新的服务，形成服务目录体系。对于数据中心，基于大数据平台的技术基础，填充特定的数据资产。这种数据资产需要分层，需要抽象建模，需要对外提供可复用的数据服务能力。所以，建设数据中心的难点，从来不在大数据技术平台，而在里面的数据建设，数据如何建模，数据如何采集，数据如何清洗，数据如何抽象聚合，等等。而这又回到了中台规划的关键，就是你需要业务领域的业务能力和经验积累，才能做到这一点。简单来说，一个企业要做数据中台，很多新兴的大数据平台或者数据中台厂商都不一定靠谱。反而是那些长期在做BI规划和实施的传统垂直领域厂商更值得托付。从云原生到企业上云，刚才我也提到了，对于阿里、华为、腾讯等公有云厂商来说，2020年会有大量云原生解决方案的宣传，助力传统企业上云。云。技术大势所趋，但企业必须意识到，从传统的内部IT架构向云端迁移，仍然是一个比较漫长的过程。尤其是当企业内部已有私有云或数据中心以及大量遗留IT系统时，要保证业务连续性的平滑迁移难度极大。每个公有云厂商都推出了自己的迁移计划和计划，包括将自己的DevOps研发集成平台扩展到企业。虽然易用性和便利性在增加，但对企业的强绑定也在增加。简单来说，你采用了一个公有云服务商的解决方案和服务，但实际上以后你要离开是比较困难的。其次，我前段时间做了一个简单的对比，就是没有直接购买虚拟机而是直接购买了数据库服务，发现整体每年的成本是比较高的。有时考虑直接购买云服务厂商的技术服务能力，但实际上很多时候还是需要有运维工程师的，这笔费用也没有省去。同时，由于企业IT系统逐步迁移，内部私有云和公有云将在较长时间内共存，包括一些传统的内部IT系统在性能上往往不适合上云要求和安全性。这些必须考虑清楚。服务治理和控制能力一些公司盲目崇拜新技术，总是希望在新系统的开发中采用最新、最高性能的技术。但实际上，在后期的管理、控制、运维等方面都存在问题。微服务也是如此。新开发的微服务拆分的时候，接口定义并没有马上发现问题，最后发现是微服务拆分的太细了，微服务之间的接口交互太少了。许多。也就是说，微服务拆分后，各个微服务仍然是紧耦合的。系统一上线，我发现整个微服务环境完全不受我控制。运行失败问题难以解决，查看日志困难，接口变更大量依赖导致无法上线。这些是整个IT组织的典型结构能力，服务管控治理能力跟不上。一开始使用新技术很酷，但后面会留下无法控制的烂摊子。中台和微服务的搭建中台是否一定要采用微服务架构？上一篇文章提到，构建中台的理想方式是使用微服务架构。但中台的核心是下沉，对外提供通用的业务能力，可以支撑上层应用的快速构建。那么当企业中存在大量遗留的IT系统时，彻底推翻原有的微服务并不是最好的方式。更好的方法是关注你搭建的中台是否提供可复用的通用业务能力作为最终衡量标准。如果做到这一点，公司就搭建了一个非常好的中台。底层是否使用微服务并不是重点。因此，中台和微服务虽然紧密结合，但实际上并没有什么必然联系。中台的建设可以不使用微服务，可以采用传统架构，也可以通过适配遗留IT系统的接口来建设。对于微服务来说，不一定体现中台的特性。微服务的核心还是在于对传统大单体的拆分。拆分后接口服务的可重用性是充分条件，但不是必要条件。不要神化低代码开发平台，回归2020年的技术发展。发现低代码开发平台是热点中的热点，大量的低代码开发平台厂商和云服务提供商应运而生。有的是传统的BPM厂商，有的是自己做快速开发平台的厂商。当然，也有完全提供零代码汇编的平台。都说这么多年没有灵丹妙药，短期内不会有大的变化。那么低代码平台本身的尴尬在哪里呢？对于中小企业来说，需要的不是低代码开发，而是直接的SaaS服务。对于SaaS服务产品，可以提供一些灵活的流程、权限、数据项的配置。够能干。对于大型企业来说，很多业务流程和业务场景，尤其是复杂的业务规则，是低代码平台无法解决的。即使解决了还是有很多复杂的脚本代码。低代码平台假设每个对象和每个功能尽可能相对独立，但实际上对于复杂的业务，对象是相关的，功能是协调集成的，业务逻辑很难配置。这些都不是低代码平台可以解决的问题。如果你真的想做一个低代码的开发平台，你会看到唯一好的方向就是垂直业务行业+业务系统。越是垂直，就越容易抽象和提供可重用的东西。也就是说，它实际上提供了一个垂直行业+垂直业务下的业务平台能力，这是最有价值的。
