腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

方丈的寺院

专栏作者

73

文章

81304

阅读量

14

订阅数

微服务如何划分

摘要作为团队架构师/技术负责人你该如何进行微服务的划分呢?在以前的文章中讨论过这个话题，可落地的DDD(4)-如何利用DDD进行微服务的划分(2)[1]，最近结合在不同的开发团队实践，又有了新的思考

方丈的寺院

2022-04-12

9850

微服务如何划分

摘要作为团队架构师/技术负责人你该如何进行微服务的划分呢?在以前的文章中讨论过这个话题，可落地的DDD(4)-如何利用DDD进行微服务的划分(2)[1]，最近结合在不同的开发团队实践，又有了新的思考

方丈的寺院

2022-04-12

9850

微服务API通过ip可访问，域名不可访问问题分析

api tcp/ip 微服务 nginx

经常会有同学遇到api通过ip可以访问，但是通过域名却不可以访问。本篇文章总结了造成这种情况可能的原因。因为与具体技术的选型、规则配置有关，所以没有深入讨论，只是列出可能性，仅供参考。

方丈的寺院

2019-08-30

2.7K0

微服务API通过ip可访问，域名不可访问问题分析

api tcp/ip 微服务 nginx

经常会有同学遇到api通过ip可以访问，但是通过域名却不可以访问。本篇文章总结了造成这种情况可能的原因。因为与具体技术的选型、规则配置有关，所以没有深入讨论，只是列出可能性，仅供参考。

方丈的寺院

2019-08-30

2.7K0

可落地的DDD(4)-如何利用DDD进行微服务的划分(2)

在前面一篇介绍了如何通过DDD的思想，来调整单体服务内的工程结构，为微服务的拆分做准备。同时介绍了我们在进行微服务拆分的时候踩过的一些坑。这篇介绍下我们最终的方案，不一定对，欢迎留言讨论。

方丈的寺院

2019-08-05

6800

可落地的DDD(4)-如何利用DDD进行微服务的划分(2)

在前面一篇介绍了如何通过DDD的思想，来调整单体服务内的工程结构，为微服务的拆分做准备。同时介绍了我们在进行微服务拆分的时候踩过的一些坑。这篇介绍下我们最终的方案，不一定对，欢迎留言讨论。

方丈的寺院

2019-08-05

6800

可落地的DDD(3)-如何利用DDD进行微服务的划分

前面两篇介绍了DDD的目标管理、DDD的工程结构调整。这篇讨论微服务的划分。微服务是目前后端比较流行的架构体系了，那么如何做好一个微服务的划分？一个微服务的粒度应该是多大呢？这篇主要介绍如何结合DDD进行领域划分。

方丈的寺院

2019-08-05

8660

可落地的DDD(3)-如何利用DDD进行微服务的划分

前面两篇介绍了DDD的目标管理、DDD的工程结构调整。这篇讨论微服务的划分。微服务是目前后端比较流行的架构体系了，那么如何做好一个微服务的划分？一个微服务的粒度应该是多大呢？这篇主要介绍如何结合DDD进行领域划分。

方丈的寺院

2019-08-05

8660

可落地的DDD的(2)-为什么说MVC工程架构已经过时

mvc是一种软件设计模式，最早由Trygve Reenskaug在1978年提出，他有效的解决了表示层，控制器层，逻辑层的代码混合在一起的问题，很好的做到了职责分离。但是在实际的编码实践过程中，你会发现这个模式随着业务的扩展，变的逻辑混乱，代码重合度很高。这里借鉴DDD思想提出一种新的工程结构。

方丈的寺院

2019-08-05

1.5K0

可落地的DDD的(2)-为什么说MVC工程架构已经过时

mvc是一种软件设计模式，最早由Trygve Reenskaug在1978年提出，他有效的解决了表示层，控制器层，逻辑层的代码混合在一起的问题，很好的做到了职责分离。但是在实际的编码实践过程中，你会发现这个模式随着业务的扩展，变的逻辑混乱，代码重合度很高。这里借鉴DDD思想提出一种新的工程结构。

方丈的寺院

2019-08-05

1.5K0

微服务化后缓存怎么做

缓存 sql 数据库微服务

最近接手的代码中遇到几个缓存的问题，存在一些设计原则的问题，这里总结一下，希望可以对你有帮助

方丈的寺院

2019-08-05

3470

微服务化后缓存怎么做

缓存 sql 数据库微服务

最近接手的代码中遇到几个缓存的问题，存在一些设计原则的问题，这里总结一下，希望可以对你有帮助

方丈的寺院

2019-08-05

3470

微服务间的调用和应用内调用的有啥区别

微服务 rpc api 数据库

目前大部分的系统架构都是微服务架构，就算没有注册中心、服务管理，也肯定是多个服务，单体服务比较少了。大家平时需要在应用内调用rpc接口也比较多，那么有没有思考过微服务之间的调用和应用内直接调用有什么区别呢？面试时是不是经常被被问到微服务呢，本篇文章针对微服务间的方法调用和应用内方法调用的有啥区别这个很小的点，谈谈我的经验

方丈的寺院

2019-08-05

8320

微服务间的调用和应用内调用的有啥区别

微服务 rpc api 数据库

目前大部分的系统架构都是微服务架构，就算没有注册中心、服务管理，也肯定是多个服务，单体服务比较少了。大家平时需要在应用内调用rpc接口也比较多，那么有没有思考过微服务之间的调用和应用内直接调用有什么区别呢？面试时是不是经常被被问到微服务呢，本篇文章针对微服务间的方法调用和应用内方法调用的有啥区别这个很小的点，谈谈我的经验

方丈的寺院

2019-08-05

8320

为什么微服务应该是事件驱动？

微服务其他分布式

建立微服务的真正道路是事件驱动，这是一个有着DDD, CQRS, Event-sourcing, event streaming, complex-event processing(CEP) 等背景以及丰富JavaEE技术经验的架构师的认识，他经历了从传统整体型monolith到微服务架构之转变，细节技术涉及从容器技术 (Docker, Kubernetes) 到JVM层 (Spring Boot 和 WildFly Swarm)到应用架构(事件, 命令, 流streaming, 原始事件, 聚合, 聚合根, 事务, CQRS, 等等)，他会在六月的Red Hat Summit演讲上详细陈述。这里他从自主性与权威性的比较角度来谈论微服务为什么应该是事件驱动，原文见：Why Microservices Should Be Event Driven: Autonomy 首先，我们使用微服务是为了构建一个业务敏捷的IT系统，也就是能跟随业务快速变化的IT系统，这样才能保证我们的业务能力始终保持竞争力。而自治系统是能够相互交互提供业务敏捷，包括如果系统发生问题怎么办？系统如何克服问题？提供业务敏捷和失败容错的系统就是自治autonomy。自治系统能够独立于彼此演进，因为他们本质上是彼此没有依赖的，改变一个服务A不会强迫系统B改变，包括引起任何其他涟漪影响，如果服务A是服务B依赖的，服务A死了，那么服务B也会死期不远。那么自治性除了微服务以外，其他方面还需要什么？如果你阅读过http://blog.christianposta.com/microservices/the-real-success-story-of-microservices-architectures/，你会知道不是技术让Netflix和亚马逊的微服务获得成功，而是组织系统结构。与敏捷系统的相同类型的一些例子包括：开源社区、城市、股票市场、蚂蚁群、成群的鸟类和其他的。它们可以进化，响应react环境，甚至持续在面对巨大的失败，事实上，它们都是属于复杂自适应系统的理论研究领域。这些系统之间的共同点是什么？目标，自治性和对环境的反应。自治意味着对“事件”的“反应react” 。当有什么事情发生时，自治者（蚂蚁人或服务）会做某些事或不做某些事，但是总体来说，是这些发生事情的事件驱动了它们的行为，想想你（作为一个独立自主与自治的人）在一天中做的事情：你醒过来，基于温度穿衣服（事件或事实），你开车和去工作（在停车灯停下来（事件），避免驾驶人发生不正常事件等）。这些都是对事件的回应。你会收到收件箱里的电子邮件，你会回应。你会从你妻子提供的文本中挑选一篇关于家庭的晚餐，等等，我们生活在对事件的反应中。建立在事件的IT系统也可以是同样拥有自主性，可扩展性和弹性应对失败。从权限到自治自主并拥抱最终一致性在大多数分布式系统实现中，我们倾向于在一个单一地理空间建立跨不可靠网络的系统，这在很多方面都是坏主意，我们倾向于调用远程对象，驱动它们做某些事情，或者我们调用一个远程服务进行数据查找，如果是购物车服务，我们需要计算购物车中所有商品的最终价格以便支付，这样购物车服务会调用计价服务，计价服务也许会调用计税服务以基于价格根据不同洲税调整最终价格，计税服务也许会调用产品目录服务，货运服务也许会调用库存服务等等，最后也许需要经过一长段调用才会结束，我们正在遵循“authority权限”模式进行数据访问，我们调用那些对数据拥有权限的服务，这有点像共享全局状态，它们也有另外一个理由，因为事务性或ACID需要这样整合在一起调用。这可能会导致瓶颈。如果服务链中的某些服务不可用，它也会导致其他服务挂起以及级联崩溃性故障。它也可能导致一些奇怪的依赖关系，比如库存服务暴露给税务服务的出数据和航运服务使用的数据会不同。或者它公开了一个单一格式的数据，但其中有很多额外的细节是这两个服务都不真正关心的。如果我们以不同方式来看这个模型？如果我们颠倒这个模型，我们不再依赖和调用那些对数据拥有权限的服务，而是依赖时间和事件（如同我们现实世界一样）重新理解上下文场景和环境。我们刚刚从周围环境发现从美国到古巴的航运刚刚推出了一个较低的税收，这是一个发生的事实，我们可以观察和反应，或者忽视不做任何事。如果我们能了解到对运送到古巴的税收现在已经降低了，那么在我们展示购物车页面时，我们就可以捕捉这样的数据以便未来可能的查询，然后我们可以有更多的自主权，我们可以在我们自己的数据库中存储该信息息或该信的衍生物，这将为我们提供的服务类型进行优化。如果我们必须对我们的服务进行版本的修改，我们就可以把重点放在我们自己的架构和数据上，而不必担心更改时其他相关服务会发生什么。什么是最终一致性？响应事件而不是“及时”查询权限系统会让我们更具有自主性，更有容错能力和弹性，

方丈的寺院

2019-08-05

8100

为什么微服务应该是事件驱动？

微服务其他分布式

建立微服务的真正道路是事件驱动，这是一个有着DDD, CQRS, Event-sourcing, event streaming, complex-event processing(CEP) 等背景以及丰富JavaEE技术经验的架构师的认识，他经历了从传统整体型monolith到微服务架构之转变，细节技术涉及从容器技术 (Docker, Kubernetes) 到JVM层 (Spring Boot 和 WildFly Swarm)到应用架构(事件, 命令, 流streaming, 原始事件, 聚合, 聚合根, 事务, CQRS, 等等)，他会在六月的Red Hat Summit演讲上详细陈述。这里他从自主性与权威性的比较角度来谈论微服务为什么应该是事件驱动，原文见：Why Microservices Should Be Event Driven: Autonomy 首先，我们使用微服务是为了构建一个业务敏捷的IT系统，也就是能跟随业务快速变化的IT系统，这样才能保证我们的业务能力始终保持竞争力。而自治系统是能够相互交互提供业务敏捷，包括如果系统发生问题怎么办？系统如何克服问题？提供业务敏捷和失败容错的系统就是自治autonomy。自治系统能够独立于彼此演进，因为他们本质上是彼此没有依赖的，改变一个服务A不会强迫系统B改变，包括引起任何其他涟漪影响，如果服务A是服务B依赖的，服务A死了，那么服务B也会死期不远。那么自治性除了微服务以外，其他方面还需要什么？如果你阅读过http://blog.christianposta.com/microservices/the-real-success-story-of-microservices-architectures/，你会知道不是技术让Netflix和亚马逊的微服务获得成功，而是组织系统结构。与敏捷系统的相同类型的一些例子包括：开源社区、城市、股票市场、蚂蚁群、成群的鸟类和其他的。它们可以进化，响应react环境，甚至持续在面对巨大的失败，事实上，它们都是属于复杂自适应系统的理论研究领域。这些系统之间的共同点是什么？目标，自治性和对环境的反应。自治意味着对“事件”的“反应react” 。当有什么事情发生时，自治者（蚂蚁人或服务）会做某些事或不做某些事，但是总体来说，是这些发生事情的事件驱动了它们的行为，想想你（作为一个独立自主与自治的人）在一天中做的事情：你醒过来，基于温度穿衣服（事件或事实），你开车和去工作（在停车灯停下来（事件），避免驾驶人发生不正常事件等）。这些都是对事件的回应。你会收到收件箱里的电子邮件，你会回应。你会从你妻子提供的文本中挑选一篇关于家庭的晚餐，等等，我们生活在对事件的反应中。建立在事件的IT系统也可以是同样拥有自主性，可扩展性和弹性应对失败。从权限到自治自主并拥抱最终一致性在大多数分布式系统实现中，我们倾向于在一个单一地理空间建立跨不可靠网络的系统，这在很多方面都是坏主意，我们倾向于调用远程对象，驱动它们做某些事情，或者我们调用一个远程服务进行数据查找，如果是购物车服务，我们需要计算购物车中所有商品的最终价格以便支付，这样购物车服务会调用计价服务，计价服务也许会调用计税服务以基于价格根据不同洲税调整最终价格，计税服务也许会调用产品目录服务，货运服务也许会调用库存服务等等，最后也许需要经过一长段调用才会结束，我们正在遵循“authority权限”模式进行数据访问，我们调用那些对数据拥有权限的服务，这有点像共享全局状态，它们也有另外一个理由，因为事务性或ACID需要这样整合在一起调用。这可能会导致瓶颈。如果服务链中的某些服务不可用，它也会导致其他服务挂起以及级联崩溃性故障。它也可能导致一些奇怪的依赖关系，比如库存服务暴露给税务服务的出数据和航运服务使用的数据会不同。或者它公开了一个单一格式的数据，但其中有很多额外的细节是这两个服务都不真正关心的。如果我们以不同方式来看这个模型？如果我们颠倒这个模型，我们不再依赖和调用那些对数据拥有权限的服务，而是依赖时间和事件（如同我们现实世界一样）重新理解上下文场景和环境。我们刚刚从周围环境发现从美国到古巴的航运刚刚推出了一个较低的税收，这是一个发生的事实，我们可以观察和反应，或者忽视不做任何事。如果我们能了解到对运送到古巴的税收现在已经降低了，那么在我们展示购物车页面时，我们就可以捕捉这样的数据以便未来可能的查询，然后我们可以有更多的自主权，我们可以在我们自己的数据库中存储该信息息或该信的衍生物，这将为我们提供的服务类型进行优化。如果我们必须对我们的服务进行版本的修改，我们就可以把重点放在我们自己的架构和数据上，而不必担心更改时其他相关服务会发生什么。什么是最终一致性？响应事件而不是“及时”查询权限系统会让我们更具有自主性，更有容错能力和弹性，

方丈的寺院

2019-08-05

8100

如何避免写出烂的业务代码（2）- DDD整改

何避免写出烂的业务代码（1）一文中介绍过如何避免写出烂的业务代码，这边谈一谈领域驱动模型的实践

方丈的寺院

2019-08-05

7740

如何避免写出烂的业务代码（2）- DDD整改

何避免写出烂的业务代码（1）一文中介绍过如何避免写出烂的业务代码，这边谈一谈领域驱动模型的实践

方丈的寺院

2019-08-05

7740

没有更多了

社区活动

RAG七天入门训练营

鹅厂大牛手把手带你上手实战

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态