今天又来聊一聊微服务。微服务相关基础文章，包括企业传统IT架构如何平滑向微服务转型，可以参考我在今日头条发表的相关文章。可以看到中台的概念比微服务的概念出来的晚。很多人觉得中台是被网络和相关厂商炒作的。最终在建设效能和投入产出比上没有达到公司的希望，而且服务敏捷性也符合企业的业务战略需求，所以现在很多人站出来拆掉中台或者反对中间平台。对于任何一个新事物来说，架构设计或者想法是好的，但是如果脱离了企业实际的业务目标、业务场景和需求，那么再好的东西也会变成垃圾。微服务到底在说什么？我不是要重新解释微服务的概念和定义，而是重新思考微服务概念的产生和应用场景。其实大家可以看到，在没有微服务概念的时候，我们在做一些类似的事情。比如我们多年前做SRM系统，本来打算在SRM系统中扩展招投标管理模块，但后来想了想发现招投标管理本身就是招投标部门管的，相对独立的业务和高度自治的功能，并与外部SRM接口。积分点也表现出粗粒度的特征。因此，我们将投标构建为一个独立的子系统。又如，某企业引入ERP系统后，发现需要在ERP上开发采购、物流、合同、预算等能力以满足需求。但实际发现，这些能力本身也与ERP松散耦合，如采购管理中的询价、谈判、流程审批等。ERP只管理最终的供应商、采购申请和采购订单，而实际上你如何形成这些文件并不重要。ERP的财务模块也是如此。ERP只关心最终的应付凭证或总账凭证，不关心这些凭证构成ERP的报销或审批流程。好吧，许多外部业务扩展实际上与ERP核心松散耦合。因此，可以看出，很多企业围绕ERP系统构建了多个独立的外部子系统，如采购、报销、预算、合同、HR和人力资源管理等。这些系统最终与ERP集成和协调。所以你可以看到，在微服务的概念出来之前，我们在做一件事。简单来说，不要把系统越做越大。系统越大，以后可能越难管理，系统本身也很难扩展和维护。如果你发现一个高度自治和松散耦合的业务，你可以考虑独立构建它。注意这其实和现在微服务讲的大单体应用应该拆分成更小的微服务是一样的。在互联网电子商务架构中，我们经常看到用户中心、订单中心、库存中心、支付中心。这不是映射回企业内部IT，拆分成类似的主数据平台、采购子系统、WMS子系统、报销子系统吗？所以并不是说原来的IT系统建起来就没有考虑拆分，而是拆分到什么程度的问题。为什么互联网先拆分微服务和单体应用？由于互联网应用的特殊性，在直接面对C端用户时，往往会出现海量数据和大并发调用。导致原有单体应用的性能无法持续，也无法扩容，无法进行后续的运维和控制，只好拆分。其次，由于PC端和APP同时存在，发现很多东西是重复开发的，需要集成，所以进一步横向拆分，前后端分离。再回到企业内部IT，一个采购系统的用户主要是采购部门的人员，业务量和并发量是完全可控的，不存在细节性能问题。独创的单集群扩容和冗余设计，充分满足业务需求。那么你此时拆分成更小的微服务的原因是什么？再次明确，传统微服务架构的转型必须由业务目标和场景驱动，而不是简单的技术驱动。比如一个集团企业是集中式的，整个集团有几十万用户在使用系统，同时还要考虑IOE。那么传统的单体应用就无法支持和扩展了。这时候，就是推动微服务的动力。任何企业的IT建设，都应该根据业务场景和业务目标要求，使用最合适的技术和工具来解决问题，而不是使用最先进的技术。任何一项先进技术，往往都需要当前企业在组织架构、项目管理、团队、技术储备、管控等方面的能力储备达到一定水平才能配合。否则，先进的技术反而会带来低效率。微服务带来了哪些问题？如果企业本身的IT成熟度还没有达到一定阶段，微服务架构落地显然是不可能的。这个原理前面已经讲过了。在企业IT建设中，如果粗粒度的业务系统以及它们之间的集成管理不好，那么细粒度的微服务模块就管理不好。即使企业的IT技术和成熟度达到了一定水平，微服务架构的推广仍然存在如下困难：一是架构设计能力的显性化导致内部问题的暴露，即输入、输出、架构设计的过程需要更加密集。团队的明确化形成了团队认同的标准工件。一个业务系统不分离的时候，虽然有架构设计和组件划分，但是这个工作属于团队内部事务。即使架构设计不合理，也可以在后期集成中通过很多workaround来解决。现在，不同的微服务模块可能会分配给两个独立的团队进行开发，原本属于自己内部黑盒的问题变成了团队间的问题。简单的说，你隐藏的或者没有规范的东西太多了，但是现在你不能再隐藏这些东西了。当你真的要把这些东西拿出来的时候，你会发现你原来的结构能力是有欠缺的。就像我们理解了一些东西，我们很难把它表达清楚，那么我们的理解就是缺乏的。我们很难系统地记下我们可以解释清楚的东西，这意味着我们说话的结构和顺序是缺乏的。二是管控要求和规范制度建设不及时。关于管控需求，我们可以看到，如果将两个微服务模块分配给同一个团队开发，如何保证开发团队保持两个模块的完全独立和解耦？不会有交叉的数据库直接调用，不会有其他直接绕过Service接口的耦合调用？如果没有完整的控制和检查系统，我们很难限制这些。三是微服务架构带来的开发复杂度的增加。只谈微服务架构的松耦合和高扩展性，不谈开发集成的复杂性的，都是耍流氓。事实上，目前很多企业对微服务架构并不是那么渴望。很多互联网企业实现微服务架构更多的是考虑到系统在巨大的业务并发量下的弹性扩展性，但实际上大部分的企业应用往往不是这样的。海量并发。其次，即使并发量增加，性能问题也可以通过优化代码本身、调优数据库或升级硬件服务器资源来更好地解决。做这些事情的成本远远低于微服务架构带来的开发复杂度增加的成本，以及后期运维管控的成本。要实现微服务模块的完全独立，微服务架构下最大的变化就是数据库也进行了拆分。如果把原来的业务系统分成5个微服务模块，理论上就是5个独立的后台数据库。而且数据库也不能随便连接访问。只有这样，微服务模块才能独立部署和管理。数据库拆分会带来两个问题。一是我们原来简单的跨表查询操作现在做不了了。我们必须调用两个微服务模块提供的服务，查询数据，然后再去逻辑层进行组合。.第二大问题是，如果一个业务操作需要同时更新两个微服务模块的数据，由于服务本身是无状态的，这种分布式事务问题很难解决。企业业务系统的一大特点是业务逻辑和规则比互联网复杂，对事务的一致性要求更高。正是这个原因，不解决分布式事务的问题，将直接导致后续的数据不一致和业务错误。项目中调用API方法可以解决的问题，只能通过调用远程WS接口来解决，这本身就增加了开发调试的复杂度。微服务模块与其他外部模块的集成和协调越少，你会发现微服务模块与传统的业务系统开发没有太大区别，但在完成任何功能时，都需要调用外部微服务的服务模块接口，其开发模式和效率都会带来巨大的变化。第四个是微服务架构下集成复杂度的增加。任何一个微服务模块的外部协调都有两点。一是模块本身需要消费和调用其他微服务模块提供的服务接口，二是模块还需要将自己的业务能力作为服务接口暴露给其他微服务模块。如果一个微服务模块要同时支持PC和APP，可以看到微服务模块暴露的服务需要统一提供给前端展示。那么可以看出，一个微服务模块需要完成自身组件层和表现层之间的集成，同时需要完成多个微服务模块组件之间的横向服务集成。如果我们将消息、日志、流程、4A等能力下放到平台层微服务模块，那么一个组件需要在平台层集成多个技术微服务模块才能运行。在如此复杂的集成场景下，要跨多个微服务模块运行复杂的横向端到端服务，涉及的模块和接口数量远远超过原来的单一系统模型。如果一个业务系统没有拆分成微服务模块，那么其他模块之间的集成和集成测试就是系统内部的事情，但是一旦拆分成多个微服务模块，那么这个集成就变成了外部第三方的责任。事情，或必须明确的事情。对于一个微服务模块来说，当需要集成的外部微服务模块和接口较多时，会带来哪些问题？这个问题很好理解，就是模块稳定与否已经不是模块本身的问题了。相反，它涉及许多外部依赖模块是否稳定。简单来说，以前我可以自己确认事物的稳定性，现在我无法确认。即使每个模块的稳定性都是90%，你会发现一旦集成到90%*90%*90%，稳定性就会急剧下降。也正是因为这个原因，我们要求在一个大的系统中，必须保证各个微服务模块的开发质量。这已经不是单个模块本身的问题，而是直接影响到大系统的质量。最后是微服务架构下的运维问题。微服务架构落地之后，运维的复杂度也成倍增加。微服务模块的任何问题都可能影响整个业务应用程序的功能。在运维过程中，我们不仅需要维护单个微服务模块，还需要监控所有接口服务的状态。如果与Docker集成，我们看到整个性能监控和问题分析都会变得很麻烦。如果我们在微服务架构实现之前发现问题，可以直接在应用服务器上查看tomcat或者jboss的日志。微服务架构实现后，应用容器已经实现了自动部署和动态分配。原有的故障诊断模式行不通，PaaS平台本身需要提供完善的预警和日志分析能力。同样，如果发现性能问题或故障，我们的解决方案是什么？如何保证微服务模块扩展时不影响业务运行，不丢失数据，不发生业务中断。这些都不是简单的部署架构层面冗余就能解决的问题，而是涉及到我们整个微服务架构中的消息策略、事务管理机制、持久化机制。浅谈微服务构建与实现中的几个问题把上面提到的内容再总结一遍，简单来说就是两点。一是企业必须有明确的业务目标和需求来推动微服务转型，而不是单纯的技术驱动。其次，如果及时有明确的需求，前期也需要进行相应的组织、团队和技术储备和积累，建立相应的管控机制，否则会导致混乱。目前批评微服务的人很多，最常见的地方就是将单体拆分成微服务过于细粒度，导致大量的微服务集成、接口滥用，以及后续无法控制和治理的问题。引入微服务本身就是为了自治和解耦。结果，最终实现完成后，你发现整个应用架构的耦合度更高了。这不是微服务的错，而是规划和架构设计不到位的错。下面谈谈微服务改造中的一些常见问题和实践思考。单个应用不拆分就不能扩展吗？单个应用程序中有数据库和应用程序两层。应用层往往容易集群扩展，而数据库最难集群扩展。如果数据库性能出现问题，应该优先考虑代码和数据库层面的SQL优化（对于大多数企业应用来说，性能问题不是服务器资源或能力不足，而是代码写得不好。），其次是相应的Read-写分离或者数据库拆分等传统单体微服务的拆分粒度？传统单体应用微服务的拆分粒度以6到8为宜，这毕竟是一个粗略的说法。但是，传统应用中有流程驱动和数据驱动两种类型。类似于OA或工单系统，它们是流程驱动的。这类应用再怎么拆分，也不会有太大的影响。对于资产系统等数据驱动的系统，一定要注意底层的共享数据不要随便分层，否则以后会引入大量的分布式事务问题。我们的实现总结了微服务拆分和数据库拆分。这两个概念需要分开。数据库拆分后，可以将对应的上层应用模块进一步拆分成多个独立的组件，暂时不考虑独立部署。如何拆分微服务？微服务拆分是业务驱动的，而不是技术驱动的。它需要对业务场景和业务流程有深刻的理解。只有经过清晰的业务分析，才能明白哪些业务功能和业务数据应该聚合在一起，这样相互之间的耦合度才最小。无论是基于传统的企业架构还是领域建模设计，核心都是基于业务驱动建模和拆分微服务。其次，微服务的拆分应该理解为两个层次的内容。一是微服务模块和数据库的拆分，二是拆分后接口的定义和标识。你用微服务框架，就是微服务吗？现在很多人理解微服务只要使用像SpringCLoud这样的微服务框架，就是微服务架构。这是一个很大的误解。微服务架构的核心在于微服务的拆分、粗粒度的API接口设计以及微服务之间的松耦合。如果达不到这个要求，就不是微服务架构。实施微服务需要哪些能力储备？技术上，关键是要熟悉主流的微服务开发框架，其次需要搭建技术能力平台，实现通用技术能力的下沉和共享，比如消息、缓存、4A、流程引擎、任务调度等.这些技术能力首先需要从微服务中剥离出来。只有这样，微服务模块才能将重心转移到业务功能的实现上。在研发和流程管理方面，重点考虑开发团队的划分，敏捷方法论的推进，其次是持续集成或DevOps的流程实践。如果这些流程管理和自动化支撑工具跟不上，微服务的实施往往会给后续的实施和运维带来巨大的工作量。举个简单的例子，原来系统部署只是一个很大的WAR包，现在变成了20个微服务模块。靠人工显然是不现实的。还是那句话，微服务的拆分实际上是匹配开发团队的。开发团队先拆分，再拆分成微服务。只有这样才能实现彻底的解耦。一个开发团队只有2个人，一个后端开发人员管理拆分后的8个微服务模块。可想而知，这个开发者是完全无法按照微服务的边界和约束去实现的。本来API接口调用反正是自己做的，变成了直接访问数据库调用。为什么微服务后耦合紧？这其实是很多企业都遇到过的问题。简单的说，就是要实现微服务架构。最好不要进行微服务改造。紧耦合本身的原因体现在两点上。一是微服务划分不合理。您应该将其拆分为两个微服务。拆分之后，发现两个微服务之间有大量的接口调用，给自己找麻烦。二是前期微服务治理管控工作不到位，尤其是微服务对外暴露的API接口的使用约束和标准规范。在一个大的微服务框架下，所有微服务共享一个服务注册中心，微服务模块暴露的API接口可以被其他微服务模块访问和消费，也就是说，微服务之间的API接口访问和使用是完全不受控制的，所以后续的多个微服务自然会出现紧耦合的问题。APM或服务链监控能否解决服务治理问题？同样，APM或服务链监控可以帮助您改进和优化性能问题和不合理的服务调用。但这已经是事后补偿操作了。一切都应该以需求和设计为驱动，一开始就避免出现问题，而不是出现问题后再去改变和优化。很多人认为反正可以通过链路监控查看服务链路调用关系和性能损失，所以在设计开发阶段，我随意调用API接口也无所谓。这是非常错误的认识。包括很多人在实践微服务的时候配合Scrum敏捷研发，导致微服务整个构建过程中没有架构设计工作，这本身就是给后期管控运维带来巨大地雷的地方。APM和链路监控缺一不可，但这绝对不是你前期偷懒的理由。高可用、高扩展、可操作首先要认识到，微服务架构下的高可用设计往往比传统单体架构的高可用更难、更复杂。前面提到，拆分微服务的原因是性能和可扩展性，以及业务能力的解耦。但需要注意的是，三者往往相互制约。微服务实现后，性能和扩展性确实提高了，但是高可用更难保证，维护也更难。很多企业在实施微服务的时候，在拆分初期很开心，但是后来发现拆分之后微服务太多了，集成的复杂度成倍增加。同时，应用出现问题后也很难快速定位问题。.这也是典型的没有考虑到三者的平衡。
