微服务改造
微服务改造
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。...(more)
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。
热点
来自主题:微服务 · 2020-04-30
尘世随缘上海某互联网金融公司 擅长领域:微服务, 微服务拆分, 熔断
86 会员关注
可以把这些和业务逻辑无关的共性需求以公共服务的方式部署,如果服务之间要依赖只需要调用公共服务提供的接口即可,切记把公共服务放到业务里面去。总的原则是服务自治原则不要破坏。...
浏览713
回答3
来自主题:微服务 · 2020-03-17
东风微鸣大地保险 擅长领域:Kubernetes, OpenShift, 容器云
4 会员关注
前言今天开始第二篇,主要介绍下Demo应用的架构.另外,我要吃掉我之前写的第一篇了,纠正如下:第一篇修订:这一次,相关的场景是这样的:SpringCloud微服务系统已经提前搞好了,并没有运行在容器平台上,而是直接运行在虚机上。这次就是结合SpringBoot的组件和K8S(OpenShift)的相关...(more)
浏览685
来自主题:微服务 · 2020-02-26
sdsfan80中国电信集团系统集成有限责任公司 
2 会员关注
收藏4
评价2
金币10
来自主题:数据中台 · 2019-12-24
1. 中台是企业级能力复用平台,它本身往往就是通过API的方式暴露给前台面向客户的应用,也就是所谓的敏态应用。所以我们说,业务中台和数据中台的技术实现方式是微服务和云原生,这两者是相辅相成的。2. 而且,业务中台和数据中台往往体现了企业组织架构的变化,往往能够推倒企业...
浏览1628
回答2
来自主题:微服务 · 2019-10-18
尘世随缘上海某互联网金融公司 擅长领域:微服务, 微服务拆分, 熔断
86 会员关注
目前java的开发工具,绝大部分都是使用Spring框架。目前微服务框架中Dubbo和Spring Cloud又占据了非常大的市场。使用Spring框架,不管是切换到Dubbo还是Spring Cloud都是非常容易的事情,关键是要看切换后需要解决什么问题?研发效率问题?性能问题?还是纯技术性的研究?...
浏览3454
回答11
来自主题:微服务 · 2019-11-14
尘世随缘上海某互联网金融公司 擅长领域:微服务, 微服务拆分, 熔断
86 会员关注
从几个层面来看企业是否具备微服务的条件1、目前技术团队是否存在瓶颈,比如性能、工作效率等?2、公司的高层是否有计划或则打算来推动微服务改造?3、目前的技术团队是否有人能带领团队做微服务的改造?4、团队成员的技术水平、运维水平如何?上面的几个问题理清楚之后,再来看是...
浏览2222
回答3
来自主题:微服务 · 2019-11-01
尘世随缘上海某互联网金融公司 擅长领域:微服务, 微服务拆分, 熔断
86 会员关注
很多团队面临这样的问题,服务到底如何拆分,怎么样的拆分是合理的,拆分后新的微服务框架和老的系统如何做兼容运行,老系统如何逐步平滑过渡到微服务架构中,而且不影响线上业务运行,也不能影响正常的项目迭代。其实,业界没有标准的方式来指导如何做拆分,我们主要围绕“拆“ 与 ”合...
浏览2308
回答2
来自主题:微服务 · 2019-07-01
匿名用户
收藏3
金币3
来自主题:微服务 · 2018-08-21
微服务,在互联网企业甚至传统行业移动端业务得到大规模采用,已然成为主流的应用架构。 微服务旨在帮助组织实现两个基本目标 - 敏捷性和规模 - 因此首先要评估组织的需求。 敏捷性:笨重单一的应用程序或ESB基础架构可能需要长达数个月的部署时间,从而导致冗长的发布周期,阻碍...
浏览3406
回答7
    描述
    微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。...(more)
    微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。
  • 提问题