微服务的经验和建议

1、建议尽量不要使用Jsp,页面开发推荐使用Thymeleaf。Web项目建议独立部署Tomcat,不要使用内嵌的Tomcat,内嵌Tomcat部署Jsp项目会偶现龟速访问的情况。

2、服务编排是个好东西,主要的作用是减少项目中的相互依赖。比如现在有项目a调用项目b,项目b调用项目c...一直到h,是一个调用链,那么项目上线的时候需要先更新最底层的h再更新g...更新c更新b最后是更新项目a。这只是这一个调用链,在复杂的业务中有非常多的调用,如果要记住每一个调用链对开发运维人员来说就是灾难。

有这样一个好办法可以尽量的减少项目的相互依赖,就是服务编排,一个核心的业务处理项目,负责和各个微服务打交道。比如之前是a调用b,b掉用c,c调用d,现在统一在一个核心项目W中来处理,W服务使用a的时候去调用b,使用b的时候W去调用c,举个例子:在第三方支付业务中,有一个核心支付项目是服务编排,负责处理支付的业务逻辑,W项目使用商户信息的时候就去调用“商户系统”,需要校验设备的时候就去调用“终端系统”,需要风控的时候就调用“风控系统”,各个项目需要的依赖参数都由W来做主控。以后项目部署的时候,只需要最后启动服务编排项目即可。

3、不要为了追求技术而追求技术,确定进行微服务架构改造之前,需要考虑以下几方面的因素:
1)团队的技术人员是否已经具备相关技术基础。
2)公司业务是否适合进行微服务化改造,并不是所有的平台都适合进行微服务化改造,比如:传统行业有很多复杂垂直的业务系统。
3)Spring Cloud生态的技术有很多,并不是每一种技术方案都需要用上,适合自己的才是最好的。

原文地址:https://www.cnblogs.com/borter/p/9570156.html

时间: 2024-10-05 05:50:07

微服务的经验和建议的相关文章

《微服务》九大特性重读笔记

http://blog.didispace.com/20160917-microservices-note/ 今天重读了Martin Fowler的<Microservices>,在此记录一下对九大特性的理解. 服务组件化 组件,是一个可以独立更换和升级的单元.就像PC中的CPU.内存.显卡.硬盘一样,独立且可以更换升级而不影响其他单元. 在"微服务"架构中,需要我们对服务进行组件化分解.服务,是一种进程外的组件,它通过http等通信协议进行协作,而不是传统组件以嵌入的方式

Re:从0开始的微服务架构:(一)重识微服务架构--转

原文地址:http://www.infoq.com/cn/articles/micro-service-architecture-from-zero?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage 导语 虽然已经红了很久,但是“微服务架构”正变得越来越重要,也将继续火下去. 各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我

从0开始的微服务架构:(一)重识微服务架构

导语 虽然已经红了很久,但是"微服务架构"正变得越来越重要,也将继续火下去. 各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我们发现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就是以高端的专业术语来讲述何为微服务架构.就是没有一个做到成熟地将技术传播出来,同时完美地照顾"初入微服务领域人员",从0开始,采用通俗易懂的语言去讲解微服务架构的系列. 所以,我们邀请青柳云的苏槐与InfoQ一起共建微服务架构专题"Re:从0开始的

漫谈何时从单体架构迁移到微服务?

面对微服务如火如荼的发展,很多人都在了解,学习希望能在自己的项目中帮得上忙,当你对微服务的庐山真面目有所了解后,接下来就是说服自己了,到底如何评估微服务,什么时候使用微服务,什么时间点最合适,需要哪些技术储备和资源投入等等,这些都是你需要面对和解决的. 本文从单体架构,微服务架构,微服务风险评估,微服务落地条件等几个方面探讨微服务的落地过程,希望对你有所启发. 讲解微服务之前,我们先简单了解下单体架构. 一.单体架构 单体架构的优点: 快速开发和验证想法,证明产品思路是否可行 投入资源和成本,包

【转】应用架构一团糟?如何将单体应用改造为微服务

概述 将单体应用改造为微服务实际上是应用现代化的过程,这是开发者们在过去十年来一直在做的事情,所以已经有一些可以复用的经验. 全部重写是绝对不能用的策略,除非你要集中精力从头构建一个基于微服务的应用.虽然听起来很有吸引力,但是风险很大,很有可能会失败.就像MartinFowler所说的: 『The only thing a Big Bang rewrite guarantees is a Big Bang!』 你应该循序渐进地重构你的单体应用.你可以逐步地构建一个部分微服务化的应用,然后和你的单

《2016ThoughtWorks技术雷达峰会----微服务架构》

微服务架构   王键,ThoughtWorks, 首席咨询师 首先微服务架构的定义,thoughtWorks在2012年3月的技术雷达中这样定义: “微服务架构是一种架构,它提倡将单一应用程序划分为一组小的服务,每个服务运行在其独立的进程中,服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API).每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产环境.类生产环境等.” 从这个定义中可以知道,如何甄别一个一个架构是不是微服务架构,可以从2点来判断. 一个是服务

SOA和微服务架构的区别?

知乎用户 289 人赞同了该回答 谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结. 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身

什么是微服务架构?

微服务(Microservices Architecture)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独立部署,各个微服务之间是松耦合的.每个微服务仅关注于完成一件任务并很好地完成该任务.在所有情况下,每个任务代表着一个小的业务能力. 单体架构(Monolithic Architecture ) 企业级的应用一般都会面临各种各样的业务需求,而常见的方式是把大量功能堆积到同一个单体架构中去.比如:常见的ERP.CRM等系统都以单体架构的方式运行,同时由于提

微服务和SOA的区别

SOA和微服务架构的区别? 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多 个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从 前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小 应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴 露的服务,同时自身也将自身的能力朝外部发布为服务. 如果一句话来谈SOA和微服务的区别,即