一、业务背景1.1产品现状1、各产品系统独立开发，代码复用率低，系统相互调用，耦合严重，系统难以解耦和独立部署。2、传统的单体架构变得越来越庞大、越来越笨重；当新功能的开发和功能的重构变得不再敏捷可控时；测试人员的回归测试边界很难弄清楚；系统的在线部署也变得困难3、高并发访问下无法提供可靠的服务4、持续集成、持续部署、持续交付等工程效率工具严重缺失。5、监控系统、日志分析等系统稳定性工具严重缺失。两者都让我们对需求的变化反应迟钝。1.2业务需求架构必须为业务需求而生。首先，让我们看一下我们面临的业务需求及其特征。平台主要满足两类业务需求：面向餐饮新零售下餐饮企业的管理运营需求，面向产品和运营团队。具体为：1、餐饮新零售下餐饮企业如何针对痛点提升营销能力和会员管理，以更低的成本为餐饮企业带来更多利润如何深度挖掘分析数据，助力决策-making如何掌握实时数据供决策者进行运营决策，让决策者及时了解餐厅运营情况2.产品导向和运营团队主要是提升产品管控能力，促进良好的运营的整体系统。因此，开发SAAS服务产品迫在眉睫，需要满足快速发展、灵活升级、高性能、高可用、高稳定性、简化运维等更高要求。这一步的转变，不是“快”与“慢”，而是“生”与“死”。2、微服务的概念关注的是职责单一、功能独立的服务，以模块化的方式组合大规模应用。2.1特点集中式架构：单体无需去中心化分布式架构：分布式压力微服务架构：分散能力2.2微服务架构优势每个微服务组件简单灵活，可以独立部署。不再像单体应用时代，应用需要庞大的应用服务器来支撑。一个小团队可以负责更专业专注，相应地更高效可靠。微服务是松耦合的，微服务内部是高内聚的，各个微服务很容易按需扩展。3.微服务技术选型和微服务问题3.1技术选型3.1.1技术矩阵结论Netflix提供了更全面的解决方案SpringCloud对Netflix有更全面的封装SpringCloud是基于SpringBoot的，团队有SpringCloud提供的基础ControlBus可以帮助实现监控嵌入式业务应用在阿里云上的部署，SpringCloud对12Factors和Cloud-Native的支持有利于在云环境下使用。3.1.2球队希望先支持休息队。希望对新技术有平滑的学习曲线，能hold住一个小团队。我希望有一个更全面的解决方案。目前团队主要使用SpringCloud+SpringBoot来实现服务。技术选型的详细分析，请查看我的《我的技术选型》的上一篇文章。3.2微服务带来的问题难以追踪依赖服务的变化。其他团队的服务接口文档过时了怎么办？依赖的服务都没有准备好，那我开发的功能怎么验证呢。有些模块是重复构建的，跨团队、跨系统、跨语言会有很多重复构建。微服务放大了分布式架构中的一系列问题，比如如何处理分布式事务？依赖服务不稳定怎么办？运维的复杂度急剧增加，例如：大量的部署对象和众多的监控进程导致整体运维复杂度的增加。我们应该遇到过以上问题，总结形成了一些自己的解决方案，比如提供文档管理、服务治理、服务模拟等工具和框架；实现统一认证、统一配置、统一日志框架、分布式汇总分析；采用全局事务方案，采用异步模拟和同步；搭建持续集成平台，统一监控平台等。微服务架构是一把双刃剑。虽然它解决了集中式架构和分布式架构的问题，但也带来了上述问题。因此，我们需要一个微服务应用平台来整体解决这些问题。4.微服务架构设计4.1微服务应用架构设计原则4.2微服务应用架构设计目标微服务架构设计的目标是满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维的更高要求.需要。4.3微服务应用总体架构微服务应用平台总体架构主要从开发集成、微服务运行容器和平台、运行时监控管理、外部通道接入等维度进行划分和考虑。开发集成：主要是构建一个微服务平台运行时需要的一些工具和仓库：需要一个微服务平台提供一些基础能力和分布式支持能力，我们的微服务运行容器会跑在这个平台上。监控治理：致力于对托管微服务在运行时的统一监控和配置。服务网关：负责与前端WEB应用、手机APP等渠道对接，对前端请求进行认证鉴权，然后进行路由转发。4.4微服务框架概述这里我们不会详细解释服务框架中的各个组件，我们会在另一篇文章中进行解释。5.微服务架构设计实现5.1基础环境三个基础环境对于企业的IT建设非常重要：团队协作环境、服务基础环境、IT基础设施。团队协作环境：主要在DevOps领域，负责从需求到规划任务，团队协作，再到质量管理，持续集成和发布。服务基础环境：指微服务应用平台，其主要目标是支持微服务应用的设计、开发和测试、运行过程中的业务数据处理、应用管理和监控。IT基础设施：主要是IaaS（VM虚拟化）和CaaS（容器虚拟化）等各种运行环境支持等实现方式。5.2服务通信服务之间的通信往往采用HTTP+REST和RPC通信协议。使用HTTP+REST，服务约束完全取决于提供者的意识。特性简单，开发使用友好。缺点：难于管理、无状态连接、缺乏多路复用、服务器推送等。RPC定义了通信双方的数据约束。大部分连接都是基于长连接来提升性能以及伴随的服务端推送、调用链路监控埋点等，增强了系统的附加能力。缺点是对调用端提出了新的要求。整体来看，RPC在性能和合约优先级上都有优势。如何扬长避短？引入GateWay层，整合REST和RPC的优点，在GateWay层提供REST访问能力。5.3服务注册/发现在之前的单体应用中相互调用时配置一个IP或者域名就可以了，但是在微服务架构下，服务提供者会很多，手动配置IP地址或者域名就成了耦合和乏味的事情。那么服务自动注册发现方案就解决了这个问题。我们的服务注册发现能力是依赖SpringCloudEureka组件实现的。服务启动时，会向服务注册中心注册要发布的服务；在运行时，如果需要调用其他微服务的接口，首先要到注册中心获取服务提供者的地址。拿到地址后，在微服务容器内部通过一个简单的负载均衡周期进行路由。EurekaServer特点：EurekaClient会缓存服务注册信息EurekaServer注册信息只保存在内存中Eureka注册只是针对应用层面的，不支持更细粒度的服务注册，比如单个服务Rest服务到EurekaServer每隔30秒发送心跳，不建议修改心跳时间。Eureka就是利用这个时间来判断集群中是否存在大规模的服务通信异常。如果15分钟内85%的服务没有更新，EurekaServer停止移除已注册的服务，确保已注册的服务信息不会丢失，EurekaServer之间的数据同步，采用全拉增量同步的方式。Eureka在分布式事务的CAP理论中满足AP5.4。集中式配置管理在微服务分布式环境中，一个系统被拆分成许多微服务，我们必须告别手动修改配置配置的运维方式。需要集中的配置管理来提高运维效率。配置文件主要包括运行前的静态配置和运行中的动态配置。静态配置通常在编译部署包之前设置。动态配置是指系统运行过程中需要调整的系统变量或业务参数。要实现集中配置管理，需要注意以下几点。配置与介质分离，需要通过制定规范来控制。配置方式要统一，格式、读写方式、变更热更新方式尽量统一，采用统一的配置框架。运行时需要配置中心统一管理业务系统中的配置信息。概念抽象：媒体是源代码编译的产物，与环境无关。它应该在多个环境中共享。例如：jar5.5统一认证认证在安全认证方面，我们采用SpringSecurityOAuth2+JWT作为安全令牌，实现统一微服务的安全认证和认证，实现微服务之间的按需隔离和安全互通。鉴权和鉴权必须是公共服务，而不是多个系统分开搭建。5.6分布式调用微服务架构下，分布式调用比传统的部署方式多，所以“在不确定的环境下，如何交付一定的服务”可以简单理解为，我所依赖的服务的可靠性无法保证时，如何保证自己能正常提供服务，不被依赖的其他服务拖累？我们采用的解决方案：合理的超时时间合理的重试机制合理的异步机制合理的限流机制（调用次数和频率），合理的降级机制，合理的熔断机制推荐SEDA架构来解决这个问题。SEDA:stagedevent-drivenarchitecture本质上是一种采用分布式事件驱动模型，使用异步模拟进行同步，非阻塞等待，资源分配隔离的解决方案。5.7DistributedTransactionsDistributedTransactions-CAPC分布式环境下多个节点的数据是否强一致A分布式服务总是能保证可用状态P网络分区容错Distributedtransactions-避免跨库事务的策略，尽可能相关表同DB2PC3PCTCC补偿模式等，耗时复杂基于MQ的最终一致性简单高效易懂将远程分布式事务拆解为一系列本地事务基于分布式事务MQ5.8服务拆分AKF扩展立方体的服务拆分方法是对应用扩展的三个维度进行抽象和归纳。X轴展开部署实例，即单系统多跑几个实例，做成集群加负载均衡的模式。Y轴上的业务区域划分是基于不同的业务拆分。Z轴数据隔离和分区。比如，当共享单车用户激增时，集群模式无法支撑。然后根据用户要求的区域进行数据分区，在北京、上海、深圳等多建几个集群。服务拆分要点低耦合高内聚：一个服务完成一个独立的功能根据团队结构：小规模团队维护，快速迭代数据库分了，也分了。5.9.1PatternverticalsplitHorizo??ntalsplit5.9.2Principle尽量不拆分，避免单表级别1000w的跨库事务，避免collapsedjoin（冗余，全局表）5.10主要有三种类型日志管理日志、系统日志、业务日志、跟踪日志。有了这些日志，就可以帮助我们在出现问题的时候获取一些关键的信息来定位问题。如果我们要做到这一点，我们可以追溯问题的根源，那么我们就需要一个能够串联整个请求调用链的标识符。这个标识可以让我们快速定位到问题的具体时间、地点和相关信息，快速恢复业务的交易全链路。这些日志和流水的详细处理，对于定位系统运维问题很有帮助。通常，开源框架只提供基础框架，而设计平台必须考虑直接提供统一标准化的基础能力。分布式追踪5.11服务契约与API管理针对上述微服务带来的依赖管理问题，我们需要提供API管理能力。说到API管理，首先要提到的就是服务契约。服务契约主要描述了服务接口的输入输出规范以及其他与服务调用集成相关的规范。5.12服务契约和服务模拟通过服务契约，研发人员可以方便地获取依赖服务的变化，并根据依赖服务的变化及时调整自己的程序，方便地进行模拟测试和验证。基于契约生成mock服务，也就是我们常说的服务挡板，这样即使我们依赖的其他服务无法提供功能，也可以通过挡板进行联调测试。5.13微服务容器我们想创建一个稳定、高效、易扩展的微服务应用。事实上，我们还需要做很多事情。如果没有统一的微服务容器，这些能力都需要构建在各个微服务组件中，很难集成在一起。有了统一的微服务运行容器和一些公共的基础服务，上述微服务架构下部分组件重复构建的问题也迎刃而解。5.14持续集成和持续部署在运维方面，我们首先要解决的就是持续集成和持续交付。方便使用持续集成环境将程序编译成媒体包和部署包，持续稳定地部署到各个环境中。概念抽象：中等：源代码编译后的产物与环境无关，应该在多个环境中共享。例如：jar配置：是环境相关的信息。部署包=配置+媒体。5.15微服务平台、容器云、DevOps的关系就微服务应用平台本身而言，不依赖于DevOps和容器云。开发的部署包可以运行在物理机、虚拟机或容器上。但是，当微服务应用平台将DevOps和容器云结合起来的时候，我们会发现持续集成和持续交付变成了一个非常简单、方便、可靠的过程。只需几个简单的步骤，即可搭建起整个开发、测试、预发布或生产环境。整个过程的复杂性被平台屏蔽了。通过三个基础环境的融合，我们可以让分散的微服务组件更加简单方便，统一管理和运维交付。5.16技术团队组织技术团队组织——小团队根据“康威定律”，软件架构是由组织结构决定的，因此根据贝索斯的“双披萨”团队理论和敏捷方法，构建一个小团队，可以有效降低沟通成本，有利于团队自治。通过让一个小团队拥有比较完善的组织架构，Leader（熟悉业务和技术）+前端工程师+后端工程师，我们往往可以独立承担一项或多项业务任务。这样，团队成员整体负责一个或几个业务模块，可以大大提高团队成员的参与感、使命感和责任感。团队成员互相帮助，具有高度的自主权。每个人要么一起成功，要么一起失败。技术团队组织——团队划分团队的划分是按照业务线来划分的。随着业务复杂度的增加，团队可以按照业务/子业务线进行划分，但也不是绝对扁平化，而是严格遵循两个披萨的原则。业务线的划分往往是按业务来细分的。技术团队负责支持所有业务线。因此，技术团队通常是按系统或业务划分的。Twopizzateam的原则适用于组织层次结构的任何部分。人多了，分裂就得继续。TechnicalTeamOrganization–Teamwork技术团队组织–ResultsOriented1.Ownership2.BiasforAction3.Eatyourdogfood工程师负责研究、设计、开发，从需求、测试、部署、维护、监控、功能升级，这意味着软件工程师负责应用程序或服务整个生命周期中的所有工作。运维是团队成员的重中之重。强大的自动化运维工具在软件工程师的支持下，软件工程师必须负责服务或应用的SLA。4.开发人员参与架构设计，而不是架构师参与开发。研发人员是Owner，对业务和团队负责，强调抽象化简，把复杂的问题分解成简单的问题，并有效解决，避免过度设计鼓励使用新技术解决问题，但强调控制六,微服务架构设计过程中积累的经验深入理解业务设计阶段追求完美，实践阶段要考虑实际情况做均衡的容错监控任何启动都可以先回滚。7.总结微服务架构是技术的升级，但更多的是管理模式的升级，思维方式的转变。
