专家简介高驰涛（NeekeGao），PHP/PECL开发团队成员，掌握近10种开发语言，9年架构师经验，6年研发管理经验。云智AIOps社区PMC，PECL/SeasLog、PECL/JsonNet、GoCrab等众多开源软件的作者。2014年加入云智，致力于APM和大数据产品的架构研发，倡导敏捷性和效率。谈几年前一个CTO的问题：“我们的系统会有5000个微服务组件，我们应该怎么做？”我们都知道接口不能称为微服务，接口的数量可能达到十几个才叫微服务。那么，如何实现和管理一个拥有5000个微服务的系统呢？如此庞大的系统背后，必然存在可以预见的大问题。微服务的前世今生微服务是如何诞生的，必须了解以下四个方面：TOGAF：全称是“OpenGroupArchitectureFramework”。TOGAF由专业组织在1970年代和80年代开发。TOGAF直到1995年美国国防部介入后才形成。今天，我们手机中使用的许多产品和应用程序都使用SAP、IBM或HP的软件，这些软件公司都遵循TOGAF。可以说，目前全球超过50%的企业都在使用TOGAF来实践软件架构设计和开发。TOGAF是一个架构体系，但它并没有提供具体的架构方法。TOGAF包括业务架构、应用架构、数据架构、技术架构等。TOGAF主要有三大支柱：企业架构域，主要是企业信息和业务流等；ADM系列架构方法论；企业连续性，指的是保证架构体系在业务快速增长和不断变化的过程中的连续性。DDD：全称是“Domain-DrivenDesign”，里面包含了很多概念，可以用三句话来概括：DDD是流水线业务。DDD首先聚焦业务，将繁琐的各种业务流程简化为更细的链条；DDD需要回答业务做什么，能满足什么需求，能达到什么目的；iteratively，DDD的持续迭代类似于TOGAF的enterprisecontinuity。SOA：全称是“Service-OrientedArchitecture”，也有很多学说，归纳起来有以下三点：SOA解决了信息孤岛问题；业务复用，从业务角度将各种服务组合成中间件或服务，提供给用户或其他系统；SOA使系统成为一个相互关联的信息群。GRASP原则：全称是“GeneralResponsibilityAssignmentPrinciple”，其中包含了很多大家耳熟能详的“低耦合”、“高内聚”等概念，这些概念都来源于GRASP原则。它不同于指导如何实现系统的设计模式，而GRASP旨在指导如何分区。GRASP原则旨在指导业务架构、API等相关内容的定义和服务的划分。它也有很多理论内容。你只需要记住三个重点：做好自己的事；做你能做的；只做你自己强调资源分区的事情。软件工程教材中给出了微服务架构的定义：微服务架构是一种架构模式，将单个应用程序划分为一组小的服务，服务之间相互协调配合，为用户提供最终价值。每个服务都运行在自己独立的进程中，服务之间使用轻量级的通信机制（通常是基于HTTP协议的RESTFulAPI）进行通信。每个服务都围绕特定的业务构建，可以独立部署到生产环境、类生产环境等。另外，要尽量避免统一集中的服务管理机制。对于具体的服务，要根据业务上下文选择合适的语言和工具来构建。而这些教科书的内容到现在可能已经过时了。微服务带来的优势当我们使用微服务架构的时候，我们到底得到了什么？这里有四个最明显的优势：让开发和迭代更加敏捷，使用微服务架构让敏捷开发成为可能；易扩容，有的公司基于Kubernetes、Docker等技术，可以秒拉起数以万计的微服务，当大规模流量冲击到来时，可以无损承载所有流量，并且在同时实现用户不知不觉，在数据访问量减少的情况下，实现快速伸缩；多技术栈是可以的，目前云智慧的技术栈非常全面。虽然只有60多个开发人员，但是却有10多种开发语言，微服务的使用可以有效组织各类开发人员；高可修改性，比如数据库的快速迁移，通道的快速切换等。微服务带来的两个问题微服务可以带来很多优势，但也有两个问题：第一个是“微服务架构，你的系统变得更健壮了吗？”；第二个是“微服务架构，你的系统变健壮了吗？”使用微服务是不是让系统变快了？”对于这两点，可能说众说纷纭，有人说因为组件越来越多，可监控性会越来越难，那么健壮性系统会变得更糟；会变得越来越强大。如果单体架构是串行的，那么微服务的使用可以使其并行和分布式，多个组件之间的通信也会让通信成为性能瓶颈。那么使用微服务是不是更快呢？是变了还是变慢了？这两个问题都很难回答。成为架构师或开发人员需要持续深入的思考。微服务架构面临的挑战与反思这里总结了使用微服务架构需要面对的8个挑战和相关注意事项：1.小即是多。当业务由大变小，也就意味着业务发生了变化。太多了。从大变小可以让系统更容易维护和修改，但是从少变多会让问题变得更复杂，所以会有很多挑战。第一个问题是多节点、多服务和多状态。当系统中有更多的节点和组件服务时，节点和服务之间的状态将变得更难维护和更复杂。基于上述四种知识，可以折衷从大到小和从少到多的两种转变，使其更可控。解决这个问题的关键在于服务的合理拆分。主要考虑三点，即数据资源、业务功能和服务对象。2.债务管理Bug、代码缺陷、未完成的功能或版本不兼容都是债务。当服务越来越多时，债务往往会越来越多。为了解决这些问题，其实有几个策略：单元测试，如果单元测试做得足够好，那么代码缺陷的可能性就会变低，服务带来的债务也能从少变多。多种情况下的收敛；集成回归，这部分提供了很多工具来做这件事，开发者不需要自己做；版本管理，这里指的是静态库的版本管理，动态库是指正在变化的库，静态库是指不再变化的库和配置项。如果这一点控制不好，很容易导致系统管理混乱；迭代冲刺是一种组织方法。当有大量的技术债需要管理时，将如何逐步处理这些债或遏制发散的趋势，迭代冲刺是一种方式；BugCrash，这是智能云团队自己发明的一个名词，相当于清理bug，不管用传统开发还是敏捷开发，每一种模式都会有一些bug，所以我们会定期组织所有的开发测试和产品使用我们自己的产品来清理错误；回归总结，无论采用什么开发模式，在完成一个迭代周期后，回归总结是必不可少的，它也需要通过一些方法来解决新的问题，或者关闭它们，这样债务才不会继续蔓延。3.复杂的服务依赖如果只有一个或者几个组件，那么服务依赖是没有问题的，但是如果组件有几千个，那么服务依赖就会成为一个巨大的问题。比如用户服务需要调用订单服务，启动时需要进行一些初始化工作，发布一个服务版本可能会导致系统完全瘫痪。这就是复杂服务依赖的问题。为了解决这个问题，首先需要一个服务发现机制，比如使用etcd或者Zookeeper。首先，服务发现中心也需要分布式和高可靠。然后，服务启动后，你需要告诉服务发现中心你的名字和调用方式，并进行注册。;对于服务调用方，只需通过约定的名称从服务发现中心获取服务调用地址即可。依靠唤醒是一个比较新的东西。比如突然来了大流量，A服务需要从原来的10个启动到100个，而B原来的3个肯定不够用，所以需要唤醒。该机制将拉起服务，而不是被动地被通知。还有一种情况需要使用依赖唤醒机制，比如缓存穿透问题。一般情况下，缓存是有效的，不会有穿透。但是缓存可能会因为某些异常而失效，大量的流量打到DB上，导致服务不可用，整个服务雪崩。为了解决这些问题，一般会开发一些挡板服务，可能会给出一些固定的数据，而这些挡板服务也可能面临这种突发流量，也需要通过依赖唤醒的机制来唤醒。另外还有灰度发布和AB测试，这两点是有关联的。还有就是多版本共存的问题，这也是多版本服务的技术债问题，需要考虑如何下线老版本。4.消息通信如果系统包含多个语言栈，则有多种实现方法。统一的标准是必须的，统一的RPC或者直接使用RestFulAPI。消息中心也是一种处理方式，在Java中被广泛使用。消息中心不是消息队列，而是事件驱动的消息中心。此外，还有一个通信网关，这也是使用微服务时必不可少的一个点。主要解决监控问题，可以通过网关起到集中控制的作用，比如安全、性能、用户验证等任务。5.分布式事务在实现分布式事务时可以使用2PC或者3PC原则来实现。2PC原理是通过所有节点投票和执行两步完成，出块；而3PC则不同，虽然在特定的事务中可以是阻塞的也可以是非阻塞的。3PC协议是通过“Can-Pre-Do”三个步骤实现的。PDU其实就是3PC协议在单体中的实现方法。在分布式系统中，3PC有三种实现方式，分别采用分布式事件驱动、最大通知、两阶段补偿TCC。6.花哨的故障在许多情况下，可能需要数周时间和大量人力才能找到系统问题的根本原因。可能是因为系统太多，系统架构师无法理清系统之间的关系。面对很多花哨的故障，也有很多应对的策略，比如全链路跟踪，比如使用OpenTracking；主动拨号测试，很多客户端APP都内置了探针，可以接收服务器的指令，定时检测接口和服务是否正常。7.集中与分权集中与分权可以说是一个永恒的话题。上图的配置、放号、日志、调度、状态、预警，其实都是针对比较成熟的大型系统。居中。8.组织危机最后一个问题是最大的问题。事实上，当要实现向微服务架构的变革时，最大的问题是组织危机。这与开发人员关系不大，但与TeamLeader和组织管理者有很大关系。架构改造需要考虑信任危机、过时维护、多语言栈、沟通协作、安全网关、岗位轮换等问题。总结起来，最重要的有两点：微服务不是灵丹妙药，不要让重复的事情做两次。写在最后近年来，在AIOps领域高速发展的背景下，各行业对IT工具、平台能力、解决方案、AI场景和可用数据集的迫切需求呈爆发式增长。基于此，云智于2021年8月发布了AIOps社区，旨在竖起开源大旗，为各行业的客户、用户、研究人员和开发者打造一个活跃的用户和开发者社区，共同贡献和解决行业问题。问题，促进该领域的技术发展。社区先后开源了数据可视化与编排平台——FlyFish、运维管理平台OMP、云服务管理平台——Moore平台、Hours算法等产品。优秀的开源项目——FlyFish：项目介绍：https://www.cloudwise.ai/flyF...Github地址：https://github.com/CloudWise-...Gitee地址：https://gitee.com/CloudWise/f...请通过以下链接了解我们，添加小助手微信（xiaoyuerwie），备注：飞鱼。申请加入开发者交流群，与行业大咖1V1交流！
