精华内容
下载资源
问答
  • 微服务拆分规范和原则

    千次阅读 2020-05-28 12:05:02
    微服务拆分没有一个绝对正确的方案,服务拆分的粒度完全要根据业务场景来规划,而随着业务的发展,原先的架构方案也需要做调整。既然没有标准答案,那我们就使出“乱拳打死老师傅”的招数,想怎么拆怎么拆好了?且慢...

    前面我们了解了什么是微服务和为什么需要做微服务架构(What & Why),这一章我们就来探讨如何做微服务架构的拆分(How)

    微服务拆分没有一个绝对正确的方案,服务拆分的粒度完全要根据业务场景来规划,而随着业务的发展,原先的架构方案也需要做调整。既然没有标准答案,那我们就使出“乱拳打死老师傅”的招数,想怎么拆怎么拆好了?且慢且慢,这不就成了暴力拆迁了吗,现在“扫黑除恶”正当头,我们可不能这么干。这里总结了几个服务拆分的心法秘籍,同鞋们可以照着这个路子去思考服务拆分的粒度,我行走江湖就靠着这套武功心法。

    拆迁方案

    这辈子当不成拆迁户的同学们,你们也别灰心,咱房子拆不成,微服务还是可以拆一拆的。说到拆迁,咱就得有一套方式方法,不能暴力拆迁。不妨看一看在下一般怎么规划拆迁方案

    1、压力模型拆分

    压力模型简单来说就是用户访问量,我们要识别出某些超高并发量的业务,尽可能把这部分业务独立拆分出来。这么做的原因非常简单,高并发业务相当于前线战场,战况非常激烈,如果我方部署兵力不够(服务器资源),而敌方攻势又过于猛烈(剁手族们疯狂的流量),万一战线失手了服务器压力抵挡不住,我们不希望让这种情况影响到其他用户场景。

    我这里举两个例子:

    • 秒杀
      秒杀是一个典型的低频突发流量的场景,参加秒杀的商品的数量一般不会很多,但是在秒杀开始的时候,尤其是对爆款商品来说(比如新发布的苹果手机),会有一个很明显的突发流量
    • 商品详情页
      商品详情页毫无疑问是电商场景中并发量最大的业务,一笔成功达成的订单背后,可能会调用几十次商品详情页接口(大家买东西都要货比三家么不是)

    我在做具体规划的时候,会尽量把压力模型拆解为三个维度

    1. 高频高并发场景
      比如商品详情页,它既是一个高频场景(时时刻刻都会发生),同时也是高并发的场景(QPS - Query per seconds极高)
    2. 低频突发流量场景
      比如前面提到的秒杀,它并不是高频场景(偶尔发生),但是它会产生突发流量。再跟大家举一个例子,那就是“商品发布”,对新零售业务来说,当开设一个线下大型卖场以后,需要将所有库存商品一键上架,这里的商品总数是个非常庞大的数字(几十万+),瞬间就可以打出很高的QPS
    3. 低频流量场景
      这一类多为后台运营团队的服务接口,比如商品图文编辑,添加新的优惠计算规则,上架新商品。它发生的频率比较低,而且也不会造成很高的并发量。

    通常我们建议将高频高并发的场景隔离出来,单独作为一个微服务模块,典型的就是商品详情页的后台服务。对低频突发流量的场景,如果条件允许也可以剥离出来独立组成模块,如果必须和其他业务包在一个微服务下,那一定要做好流控措施(最典型的就是削峰策略),而且还要考虑到异常情况下的补偿机制。对于低频流量场景,我们根据业务模型切分就好了(后面会讲到)。

    2、业务模型拆分

    业务模型拆分的维度有很多,我们在实际项目中应该综合各个不同维度做考量。我这里主要从主链路、领域模型和用户群体三个维度来讲一下

    2.1 主链路拆分

    在电商领域“主链路”是一个很重要的业务链条,它是指用户完成下单场景所必须经过的场景。按照我们平时买买买的剁手经验,可以识别出很多核心主链路,比如商品搜索->商品详情页->购物车模块->订单结算->支付业务,这是就是一条最简单的主链路。如果这是一场战斗的话,那么主链路就是这场战斗的正面战场,我们必须力保主链路不失守。

    电商领域背后还有很多隐藏的核心主链路,比如下单之前的营销优惠结算,它会影响订单的最终价格;再比如用户地址模块,它会影响下单前的配送地址选择。如果这两个模块出了问题,大部分用户恐怕都要放弃下单了。试想,双十一我们添加了一揽子购物车,结果结算的时候发现所有优惠组合都失效了,或者是无法选择配送地址,那也只好放弃了。

    各位亲,这里建议将核心主链路拆分,有以下几个目的:

    1. 异常容错
      为主链路建立层次化的降级策略(多级降级),以及合理的熔断策略,这部分我们将在Hystrix服务容错阶段的课程中详细解释
    2. 调配资源
      主链路通常来讲都是高频场景,自然需要更多的计算资源,最主要的体现就是集群里分配的虚机数量多。举个例子,就说淘系中台业务中单品营销优惠微服务,在平日非大促阶段(非双11扩容场景)一个服务后台都有接近一万台虚机,一到了发布窗口就要通宵达旦做发布。将主链路服务单独隔离出来,这样有利于根据需要指定资源计划(比如双11阶段为每个主链路服务拟定不同的扩容计划)
    3. 服务隔离
      主链路是主打输出的C位,把主链路与其他打辅助的业务服务隔离开来,避免边缘服务的异常情况影响到主链路。

    2.2 领域模型拆分

    领域驱动设计DDD(Domain-Driven Design 领域驱动设计)不是一个新概念,但老外们有个毛病,做什么事情特别喜欢提炼方法论,本来一个非常简单的概念,愣是被吹到神乎其神高深莫测。

    其实领域模型是一个很简单的概念,抛掉繁文缛节的方法论,我们一样可以做好领域模型拆分。我举一个例子大家就明白了。阿里集团推出了一套大中台战略,将集团内部的公共领域服务从各个事业部中剥离出来,整合成了一个“集团级别”的大型中台业务。比如说IC订单系统,淘系商品服务,UMP营销优惠服务,汇金平台,用户账号系统等等。

    从上面这个例子中我们可以看出,所谓领域模型,其实就是一套各司其职的服务集合。这里涉及到领域和合并和分拆。领域合并的例子就是淘系的营销优惠服务,曾经天猫和淘宝各有一套营销服务,如果不考虑底层技术,从业务层面来说它们做的事情是一样的,都属于营销优惠计算的领域范围,因此后面两条技术线整合成了一套UMP营销优惠服务。领域拆分的例子就太多了,我们做微服务规划的时候要确保各个领域之间有清晰的界限,比如商品服务,和订单服务,尽管他们之间有交集(都围绕商品主数据),但是毕竟是服务于不同领域(商品域和订单域),所以我们要将两者拆分成独立的服务。

    2.3 用户群体拆分

    根据用户群体做拆分,我们首先要了解自己的系统业务里有哪些用户,比如说电商领域,我们有2C的小卖家,也有2B的大客户,在集团内部有运营、采购、还有客服小二等等。对每个不同的用户群体来说,即便是相同的业务领域,也有该群体其独有的业务场景。

    用户群体相当于一个二级域,我们建议先根据主链路和领域模型做一级域的拆分,再结合具体的业务分析,看是否需要在用户领域方向上做更细粒度的拆分。

    2.4 前后台业务分离

    同学们如果下了班当过顺丰车主的话,就会知道网约车业务不仅有一个乘客端app,也有一个司机端app。电商领域也是一样的,我们通过手淘app买买买(前台业务场景),商家通过后台的业务系统管理商品信息(后台业务场景)。在实际项目中通常也会将前台业务和后台业务做一个隔离,这也符合高频业务(前台)和低频业务(后台)的隔离策略。

    展开全文
  • 微服务合并拆分原则

    2021-06-07 17:11:41
    拆分原则 单一职责:高内聚,低耦合,实现单一功能,如单表操作。 颗粒度适当:100个接口不能拆100个服务,适当的分组。 团队结构:1个系统不能由2个团队维护,需要根据团队负责内容进行拆分。 业务模型:不同的...

    几个要素

    • 人数:同一个服务维护的人员过多

    • 业务:对不同业务进行拆分,防止相互影响

    • 性能:一个功能消耗的性能过大,可以独立出来。分库分表也是这种体现。

    • 组织结构:不同团队间代码需要进行拆分,减少相互干扰

    • 安全:对于核心代码需要进行权限隔离,防止核心代码泄露

    • 替代性:通用性的功能需要进行独立,可以减少重复开发和不一致性。

    • 交付性/复杂度:对于需要快速交付的项目需要独立,防止项目过于复杂,导致回归测试过于复杂,影响交付速度。

    • 技术栈:不同技术实现不同功能,需要根据技术栈进行拆分

    • 业务需求:根据也许提出如高性能、高可用或快速伸缩等需求,对项目进行相应的拆分,增加相应的指标。

    拆分原则

    1. 单一职责:高内聚,低耦合,实现单一功能,如单表操作。
    2. 颗粒度适当:100个接口不能拆100个服务,适当的分组。
    3. 团队结构:1个系统不能由2个团队维护,需要根据团队负责内容进行拆分。
    4. 业务模型:不同的业务模型进行独立项目。
    5. 演进拆分:项目起步时可以不需要太拆分过细,根据项目规模逐步拆分
    6. 避免环形和双向依赖:拆分后的项目避免相互依赖或者循环依赖。

    合并原则

    减少服务间调用的性能损耗

     

     

    展开全文
  • 微服务与单体服务的拆分原则

    千次阅读 2019-08-26 17:19:22
    (1)、微服务拆分原则:领域模型、组织结构、康威定律、单一职责 (2)、微服务拥有独立数据库 (3)、微服务之间确定服务边界 2、数据一致性 (1)、可靠性事件模式 (2)、补偿模式-sagas模式 3、服务通信 (1)、通信...

    表级锁的争用状态变量:
    show status like ‘table%’;

    行级锁争用状态变量:
    show status like ‘innodb_row_lock%’;

    在这里插入图片描述

    单体架构的优势:
    1、便于开发
    2、易于测试
    3、易于部署

    单体架构的不足:
    1、复杂性高
    2、交付效率低:构建和部署耗时长
    3、伸缩性差:只能按整体横向扩展,无法分模块垂直扩展,IO密集型模块和CPU密集型模块无法独立升级和扩容
    4、可靠性差:一个BUG可能引起整个项目的运行
    5、阻碍技术创新

    微服务架构的优势:
    1、易于开发和维护
    2、独立部署
    3、伸缩性强
    4、与组织结构相匹配
    5、技术异构性

    微服务面临的挑战:
    1、服务拆分:
    (1)、微服务拆分原则:领域模型、组织结构、康威定律、单一职责
    (2)、微服务拥有独立数据库
    (3)、微服务之间确定服务边界
    2、数据一致性
    (1)、可靠性事件模式
    (2)、补偿模式-sagas模式
    3、服务通信
    (1)、通信技术方案:RPC、REST、异步消息
    (2)、服务注册和发现
    (3)、负载均衡
    4、服务网关:
    (1)、API Gateway
    (2)、为前端服务的后端
    (3)、身份认证、路由服务、流量控制、日志统计
    5、高可观察
    (1)、健康检测、集中控制
    (2)、日志聚合及检索
    (3)、分布式追踪
    6、可靠性(客户端实现):
    (1)、流量控制、超时控制
    (2)、舱壁隔离(线程隔离),熔断机制
    (3)、服务降级,幂等重试

    微服务拆分原则:
    1、单一职责、高内聚低耦合
    2、微服务粒度适中
    3、考虑团队结构
    4、以业务模型切入
    5、演进式拆分
    6、避免环形依赖与双向依赖
    7、DDD

    微服务拆分步骤:
    1、分析业务模型:
    (1)、弱耦合在一起
    (2)、高内聚力
    2、确定服务边界:
    (1)、服务应包含单一的界限上下文
    3、微服务数据库拆分

    微服务数据一致性:
    1、分布式事务不适用微服务
    (1)、2PC会有单点故障
    (2)、由于锁的原因降低吞吐量
    (3)、Nosql数据库并不支持
    2、采用最终一致性来实现数据一致性
    (1)、可靠性事件模式:消息队列(支付宝转余额宝)
    (2)、补偿模式-sagas模型:一些列的有序事务(每一个事物都有补偿子事务)

    技术选型的三要素:
    1、技术选型的广度和深度:
    2、把握和分析技术选项的优缺点
    3、紧密结合项目和团队的情况

    Eureka简介:
    1、支持跨机房的高可用
    2、数据一致性是数据最终一致性
    3、Eureka Client会对服务注册表进行缓存,降低Eureka的压力,进一步增强了它的高可用

    借助logbook输出HTTP日志
    1、pom添加logbook依赖
    2、在服务提供者工程添加logbook filter以输出日志
    3、在服务消费者工程httpclient添加logbook拦截器

    JWT介绍:
    1、基于token的进行身份验证的方案
    2、jwt设计一个字符串由header、payload、signature组成
    3、具备安全、自包含、紧凑等特点

    JWT优点:
    1、安全性高,防止token被伪造和篡改
    2、自包含,减少存储开销
    3、跨语言,支持多种语言的实现
    4、支持过期,发布者等校验

    JWT注意事项:
    1、消息体是可以被base64解密成铭文
    2、jwt不适合存放大量信息
    3、无法作废未过期的jwt(可以借用Redis实现)

    Redis的score机制:
    可以做商品或房屋的热门商品,每点击一个商品的详情,就往Redis(zset)中添加一个,并只留排名前10的;

    级联故障解决方案:
    1、舱壁隔离(线程隔离)
    2、超时控制
    3、服务降级
    4、熔断机制

    在这里插入图片描述

    Spring Cloud Sleuth原理:使用的是ThreadLocal,使用的是异步线程
    1、疑问:(spring.factories)
    (1)、追踪数据是如何生成的
    (2)、追踪数据是如何再进程内和进程间传递的
    (3)、如何解决跨线程池问题的

    进程内根据ThreadLocal进行数据的传递
    Hystrix是跨线程池的,业务线程和调用线程是隔离的

    用户请求—》TraceFilter—》Trace拦截器—》Controller—》HystrixCallable

    —》TraceRestTemplate—》TraceAspect—(可以通过MQ,也可以通过Http请求上报)—》Zipkin Server(ES、Mysql做数据存储)

    日志检索方案:
    1、ELK介绍
    (1)、Elasticsearch(日志存储)
    (2)、LogStash(负责日志收集)
    (3)、Kibana(进行日志图形化展示)

    查看日志信息:less info.log

    本地缓存:
    private final Cache<String, String> registerCache =
    CacheBuilder.newBuilder().maximumSize(100).expireAfterAccess(15, TimeUnit.MINUTES)
    .removalListener(new RemovalListener<String, String>() {

            @Override
            public void onRemoval(RemovalNotification<String, String> notification) {
              String email = notification.getValue();
              User user = new User();
              user.setEmail(email);
              List<User> targetUser = userMapper.selectUsersByQuery(user);
              if (!targetUser.isEmpty() && Objects.equal(targetUser.get(0).getEnable(), 0)) {
                userMapper.delete(email);// 代码优化: 在删除前首先判断用户是否已经被激活,对于未激活的用户进行移除操作
              }
    
            }
          }).build();
    

    private final Cache<String, String> resetCache = CacheBuilder.newBuilder().maximumSize(100).expireAfterAccess(15, TimeUnit.MINUTES).build();

    微服务的消费模式:
    1、服务直连模式(RestTemplate)特点:简洁明了、平台语言无关性、无法保证服务的可用性、生产环境比较少用
    2、客户端发现模式:
    (1)、服务实例启动后,将自己的位置信息提交到服务注册表
    (2)、客户端从服务注册表进行查询,来获取可用的服务实例
    (3)、客户端自行使用负载均衡算法从多个服务实例中选择出一个
    3、服务端发现模式

    微服务的消费者:
    1、HttpClient(RestTemplateBuilder)
    2、Ribbon(基于客户端的负载均衡器(加权、随机、轮询算法))(RestTemplateBuilder+配置)
    3、Feign:

    使用API网关的意义:
    1、API网关的意义:
    (1)、集合多个API
    (2)、统一API入口
    2、常见API网关的实现方式:nginx、zuul、getaway

    API网关带来的好处:
    1、避免将内部信息泄露给外部
    2、能给API添加额外的安全层
    3、可以降低API调用的复杂度
    4、微服务模拟与虚拟化

    zuul简介:
    1、功能:认证、压力测试、动态路由、负载削减、安全、静态响应处理、主动交换管理等

    服务熔断:
    1、断路器
    2、断路器模式

    熔断器的意义:
    1、好处:
    (1)、系统稳定
    (2)、减少性能损耗
    (3)、及时响应
    (4)、阀值可定制

    熔断器的功能:
    1、异常处理
    2、日志记录
    3、测试失败的操作
    4、手动复位
    5、加速断路
    7、重试失败请求

    微服务的高级主题----自动扩展
    1、什么是自动扩展
    (1)、垂直扩展:就是升级(双核变四核)
    (2)、水平扩展:就是数量变多(1台主机增加到4台主机)
    2、自我注册和自我发现(服务注册表(Eureka)、客户端、微服务实例)
    3、自动扩展的意义:
    (1)、提高了高可用性和容错能力
    (2)、增加了可伸缩性
    (3)、具有最佳使用率,并节约成本
    (4)、优先考虑某些服务或服务组

    自动扩展的常见模式:
    1、自动扩展的不同级别:应用程序级别、基础架构级别

    如何实现微服务的自动扩展:
    1、要思考的问题:
    (1)、如何管理数千个容器
    (2)、如何监控他们
    (3)、在部署工作时如何应用规则和约束?
    (4)、如何利用容器来获得资源效率?
    (5)、如何确保至少有一定数量的最小实例正在运行?
    (6)、如何确保依赖服务正常运行?
    (7)、如何进行滚动的升级和优雅的迁移?
    (8)、如何回滚错误的部署?
    2、所需功能:依赖两个关键功能
    (1)、一个容器抽象层,在许多物理或虚拟机上提供统一的抽象
    (2)、容器编排和初始化系统在集群抽象之上只能管理部署
    3、容器编排:
    (1)、容器编排工具提供了一个抽象层来处理大规模的集装箱部署
    (2)、具备发现、资源管理、监控和部署等功能
    3、容器编排工作职能:
    (1)、集群管理
    (2)、自动部署
    (3)、可伸缩性
    (4)、运行状况监控
    (5)、基础架构抽象
    (6)、资源优化
    (7)、资源分配
    (8)、服务可用性
    (9)、敏捷性
    (10)、隔离

    资源分配常用算法:
    1、常用算法:
    (1)、传播:将负载平均分配到各个主机上
    (2)、装箱:负载先把第一台主机用完了,在用其它主机,按需付费
    (3)、随机:负载随机选择主机

    常见容器编排技术:
    (1)、Docker Swarm
    (2)、Kubernetes
    (3)、Apache Mesos

    展开全文
  • 微服务——服务拆分策略与原则

    千次阅读 2020-09-17 09:40:05
    我们应该按照什么原则将现有的业务进行拆分?是否拆分得越细就越好?这里我想结合易企秀商城服务(以下简称商城)的实际情况谈谈服务拆分的策略和坚持的原则。 1.服务拆分策略 1.1根据业务能力进行服务拆分和定义 ...

    微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,同时,随着Docker容器技术和自动化运维等相关技术发展,微服务变得更容易管理,这给了微服务架构良好的发展机会。在做微服务的路上,拆分服务是个很热的话题。我们应该按照什么原则将现有的业务进行拆分?是否拆分得越细就越好?这里我想结合易企秀商城服务(以下简称商城)的实际情况谈谈服务拆分的策略和坚持的原则。

    1.服务拆分策略

    1.1根据业务能力进行服务拆分和定义

    创建微服务架构的策略之一就是采用业务能力进行服务拆分。业务能力是一个来自于业务架构建模的术语。业务能力是指一些能够为公司(或组织)产生价值的商业活动。特定业务的业务能力取决于这个业务的类型。例如,易企秀商城现在的业务能力包括商品管理、订单管理、价格管理、各种配置管理等等。

    识别业务能力

    组织的业务能力通常是指这个组织的业务是做什么,它们通常都是稳定的。与之相反,组织采用何种方式来实现它的业务能力,是随着时间不断变化的。这个准则在今天尤其明显,很多新技术在被快速采用,商业流程的自动化程度越来越高。一个组织有哪些业务能力,是通过对组织的目标、结构和商业流程的分析得来的。每一个业务能力都可以被认为是一个服务,除非它是面向业务的而非面向技术的。

    把商城的业务能力逐一列出来似乎也并不太困难,如下所示。

    • 商品管理

    product management:商品基础信息管理(包括翻页H5、轻设计、长页、易表单等商品)

    • 价格管理

    price management:商品价格管理,例如商品原价、折扣价、会员价和会员折扣价

    • 配置管理

    config management:配置管理,管理商城各种banner图、角标、热门搜索词、导航栏等

    • 订单管理

    order management:订单管理,消费者创建订单,运营管理订单

    • 分类属性管理

    category management:管理商品的分类

    attribute management:管理商品的属性

    • 其他

    顶级能力包括供商品管理、价格管理、配置管理、分类属性管理和订单管理。当然还有其他的顶级能力,这里没有一一列举。大多数顶级能力都会分解为子能力。例如,配置管理被分解为五个子能力。接下来,我们将了解如何使用业务能力来定义服务。

    从业务能力到服务

    一旦确定了业务能力,就可以为每个能力或相关能力组定义服务。图1显示了商城应用程序从能力到服务的映射。决定将哪个级别的能力层次结构映射到服务是一个非常主观的判断。我对这种特定映射的理由如下:

    • 将价格管理映射到自己的独立服务,因为商品的价格虽然是商品的一个属性,但是变动频繁。
    • 将配置管理的子能力映射为多个服务,是因为每种配置都有自己的独特性。

    图1:

     

     

     

    围绕能力组织服务的一个关键好处是,因为它们是稳定的,所以最终的架构也将相对稳定。架构的各个组件可能会随着业务的具体实现方式的变化而发展,但架构仍保持不变。话虽如此,但是随着我们对应用程序领域的了解越来越多,它们可能会随着时间的推移而变化,特别是架构定义流程中的一个重要步骤是调查服务如何在每个关键架构服务中协作。例如,你可能会发现由于过多的进程间通信而导致特定的分解效率低下,导致你必须把一些服务组合在一起。相反,服务可能会在复杂性方面增长到值得将其拆分为多个服务的程度。

    1.2根据子域进行拆分

    领域驱动为每一个子域定义单独的领域模型。子域是领域的一部分,领域是 DDD 中用来描述应用程序问题域的一个术语。识别子域的方式跟识别业务能力一样:分析业务并识别业务的不同专业领域,分析产出的子域定义结果也会跟业务能力非常接近。商城的子域包括:商品、订单、搜索、配置、分类属性等等。正如你所见:这些子域跟我们之前定义的业务能力非常接近。图2 展示了子域和服务之间的映射,每一个子域都有属于它们自己的领域模型。

    DDD 把领域模型的边界称为限界上下文(bounded contest)。限界上下文包括实现这个模型的代码集合。当使用微服务架构时,每一个限界上下文对应一个或者一组服务。换一种说法,我们可以通过 DDD 的方式定义子域,并把子域对应为每一个服务,这样就完成了微服务架构的设计工作。(根据DDD的子域设计服务,可以参阅:https://microservices.io/patterns/decomposition/decompose-by-subdomain.html

    图2:

     

    按子域分解和按业务能力分解是定义应用程序的微服务架构的两种主要模式。但是,也有一些有用的拆分指导原则源于面向对象的设计。

    2.拆分的指导原则

    单一职责原则( SRP)

    软件架构和设计的主要目标之一是确定每个软件元素的职责。单一职责原则如下:

    改变一个类应该只有一个理由。—Robert C. Martin

    类所承载的每一个职责都是对它进行修改的潜在原因。如果一个类承载了多个职责,并且互相之间的修改是独立的,那么这个类就会变得非常不稳定。遵照 SRP 原则,你所定义的每一个类都应该只有一个职责,因此也就只有一个理由对它进行修改。

    我们在设计微服务架构时应该遵循 SRP 原则,设计小的、内聚的、仅仅含有单一职责的服务。这会缩小服务的大小并提升它的稳定性。

    闭包原则(CCP)

    在包中包含的所有类应该是对同类的变化的一个集合,也就是说,如果对包做出修改,需要调整的类应该都在这个包之内。—— Robert C. Martin

    这就意味着,如果由于某些原因,两个类的修改必须耦合先后发生,那么就应该把它们 放在同一个包内。也许,这些类实现了一些特定的业务规则的不同方面。这样做的目标是当业务规则发生变化时,开发者只需要对一个交付包做出修改,而不是大规模地修改(和重新编译)整个应用采用闭包原则,极大地改善了应用程序的可维护性。

    在微服务架构下采用 CCP原则,这样我们就能把根据同样原因进行变化的服务放在一个组件内。这样做可以控制服务的数量,当需求发生变化时,变更和部署也更加容易。理想情况下,一个变更只会影响一个团队和一个服务。CCP 是解决分布式单体这种可怕的反模式的法宝。

    单一职责原则和闭包原则是 Bob Martin 制定的十一项原则中的两项。它们在开发微服务架构时特别有用。在设计类和包时可以使用其余的九个原则。

     

    展开全文
  • 微服务拆分原则

    2021-01-15 17:22:32
    文章目录微服务拆分原则 微服务拆分原则 拆分的大原则是当一块业务不依赖或极少依赖其它服务,有独立的业务语义,为超过 2 个的其他服务或客户端提供数据,那么它就应该被拆分成一个独立的服务模块 单一职责、高...
  • 微服务拆分微服务拆分时机为了快速迭代高并发场景可重用提交代码经常冲突小功能要积累到大版本才能上线服务拆分原则原则一:高内聚和低耦合。原则二:服务拆分正交性原则原则三:服务粒度适中、演进式拆分原则四:...
  • 微服务拆分参考原则列表

    千次阅读 2021-03-03 13:15:57
    因为服务粒度设计过大,不能得到微服务架构带来的便利,例如:更加敏态的开发,更频繁的版本发布,由于服务功能划分的小,可以根据实际的业务场景,选择更加合适的技术进行代码重构等等。 但同时我们也要注意,不是...
  • 微服务架构拆分

    2019-11-12 11:32:47
    3微服务应基于业务能力进行构建; 4采用自动化部署机制实现微服务的独立部署; 5服务的管理应采用最小的中心化管理。 微服务架构拆分和落地 微服务架构1.0-中心化(统一语言和数据库等,落地...
  • 转载:...为什么需要应用拆分 我以淘宝技术架构演进为例,淘宝从一个大系统工程向分布式架构演变过程,你就能很清楚的知道为什么要需要进行应用拆分。 1 人员的角度。 维护一个代名工程Denali...
  • 今天我们就来聊聊微服务的设计原则和演进策略。 最常见的单体遗留系统 如果我们面对的是一个单体遗留系统,只需要将部分功能独立为微服务,而其余仍为单体,整体保持不变,比如将面临性能瓶颈的模块拆分为...
  • 1) AKF 拆分原则 2) 前后端分离原则 3) 无状态服务 4) RestFul 的通信风格 1 AKF 拆分原则 业界对于可扩展的系统架构设计有一个朴素的理念,就是: 通过加机器(水平扩展)就可以解决容量和可用性问题 。( 如果一台...
  • AKF拆分原则业界对于可扩展系统架构设计有一个朴素的理念:通过加机器就可以解决容量和可用性问题。这一理念在云计算概念疯狂流行的今天,得到了广泛的认可,对于一个规模迅速增长的系统而言,容量...
  • 微服务拆分原则和方法

    万次阅读 2018-05-30 10:11:47
    1. 单一职责、高内聚低耦合2. 服务粒度适中3. 考虑团队结构4. 以业务模型切入5. 演进式拆分6. 避免环形依赖与双向依赖
  • 微服务该如何拆分

    2021-01-19 08:43:53
    微服务的拆分一直是历史性的难题,行业内更是没有具体的拆分标准,拆分的好坏更多取决于拆分者的经验,并经过反复迭代,逐步优化、调整,以达到比较合适的划分。本文包括微服务的拆分时机、拆分原则...
  • 微服务拆分原则和方法:  单一职责、高内聚低耦合;  服务粒度适中;  考虑团队结构:(康威定律:设计系统的组织其产生系统的设计和架构等价于组织间的沟通结构。就是指每个团队开发设计和测试发布自己团队的...
  • 一、AKF拆分原则  业界对于可扩展系统架构设计有一个朴素的理念:通过加机器就可以解决容量和可用性问题。  这一理念在云计算概念疯狂流行的今天,得到了广泛的认可,对于一个规模迅速增长的系统而言,容量和...
  • 1,Y轴(功能)关注应用中功能划分,基于不同的业务拆分 2,X轴(水平扩展)关注水平扩展,也就是“加速器解决问题” 3,Z轴(数据分区)关注服务与数据的优先级划分,如按地域划分 二、前后端分离原则 三、无...
  • 业务模型拆分:前后台业务拆分、主链路查费、领域模型拆分、用户群体拆分 压力模型拆分:对于高并发量的业务,尽可能独立成微服务拆分 1.压力模型拆分 压力模型拆分,就是说根据用户对业务的访问量的高频进行拆分,...
  • 微服务设计、拆分原则-AFK

    千次阅读 2019-11-21 11:20:04
    一、AKF拆分原则  业界对于可扩展系统架构设计有一个朴素的理念:通过加机器就可以解决容量和可用性问题。  这一理念在云计算概念疯狂流行的今天,得到了广泛的认可,对于一个规模迅速增长的系统而言,容量和...
  • 微服务及微应用拆分原则This post defines microservices via seven tenets, reverse-engineered from books, articles and blogs. It also recapitulates which Service-Oriented Architecture (SOA) principles ...
  • 微服务需要拆分到什么程度?

    千次阅读 2019-10-15 13:06:47
    那么我们应该按照什么原则将现有的业务进行拆分?是否拆分得越细就越好?本文将研究把应用程序分解为服务的策略和指南、分解的障碍以及如何解决它们。 作者:克里斯·理查森 译者:喻勇 来源:《微服务架构设计模式...
  • 服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性。最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余。 开发者在刚开始尝试实现自己的微服务架构...
  • 微服务拆分

    2018-12-05 16:15:56
    三个火枪手原则就是一个微服务由三个人负责开发。一般来说,在进行微服务架构时,根据团队规模来划分微服务数量是合理的。 而为什么是3个人???? 从系统规模来讲,3 个人负责开发一个系统,系统的复杂度刚好...
  • 单体架构的优势: 1、便于开发 2、易于测试 3、易于部署 单体架构的不足: 1、复杂性高 2、交付效率低:构建和部署耗时长...微服务架构的优势: 1、易于开发和维护 2、独立部署 3、伸缩性强 4、与组织结构相匹配...
  • 拆分原则: 单一职责、服务粒度适中、考虑团队结构、以业务模型切入、演进式拆分、避免环形依赖和双向依赖拆分步骤: 分析业务模型、确定服务边界、模块拆分、数据库拆分...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,030
精华内容 5,212
关键字:

微服务业务拆分原则