中小银行做微服务有必要一定要容器化吗?

现在中小银行都在往微服务化这个方向去更新迭代自己的业务及技术架构。企业做微服务有必要一定要容器化吗?

14回答

yujin2010goodyujin2010good  系统工程师 , 大型零售巨头
我爱大锅饭yinxinitjava赞同了此回答
微服务和容器化是非常紧密关系,不是必须关系,如果微服务规模较小,不如3-5个,且并发不大,或者短期内并发变化不大,做与不做看心情。如果说规模很大,比如一个项目有50个微服务,平均每个微服务至少部署4个,这就是200,且并发变化较大,这样使用容器就能快速部署,自动扩容和缩容。 开发和测...显示全部

微服务和容器化是非常紧密关系,不是必须关系,如果微服务规模较小,不如3-5个,且并发不大,或者短期内并发变化不大,做与不做看心情。
如果说规模很大,比如一个项目有50个微服务,平均每个微服务至少部署4个,这就是200,且并发变化较大,这样使用容器就能快速部署,自动扩容和缩容。

开发和测试来说也能快速测试,迭代。

其实我觉得还是根据公司业务的特点来选择,当然如果条件成熟,微服务和容器并进比较好,当然也要看应用类型,有些传统的应用也不太适合。(比如需要key的,不能宕机,自动启动一个的)

收起
 3天前
浏览183
gavin_zhanggavin_zhang  系统架构师 , 某股份制银行
yinxinzhuhaiqiang徐生韦赞同了此回答
前提是微服务的规模有多大。中大规模的系统:从目前的技术趋势和以往的实践来看,微服务和容器化部署还是结合比较紧密的。微服务系统一旦上了规模,成千上万个服务实例的运维是一个很大的挑战。容器和容器编排正是解决多服务和多实例的部署,维护,流量控制等问题的解决方案。而且...显示全部

前提是微服务的规模有多大。
中大规模的系统:从目前的技术趋势和以往的实践来看,微服务和容器化部署还是结合比较紧密的。微服务系统一旦上了规模,成千上万个服务实例的运维是一个很大的挑战。容器和容器编排正是解决多服务和多实例的部署,维护,流量控制等问题的解决方案。而且是目前来说最好的解决方案。
小系统(小于50个服务实例)可以考虑用自动化部署工具支持。

收起
 2019-10-24
浏览787
aixchina 邀答
yeefoneyeefone  技术经理 , 某大型保险公司
yinxinzhuhaiqiang徐生韦赞同了此回答
不一定。可以尝试在部分业务上尝试容器化,积累经验,具体要看使用方的技术积累和团队能力,不易过早过快的推进容器化。显示全部

不一定。可以尝试在部分业务上尝试容器化,积累经验,具体要看使用方的技术积累和团队能力,不易过早过快的推进容器化。

收起
 2019-10-24
浏览717
尘世随缘尘世随缘  技术总监 , 上海某互联网金融公司
yinxinzhuhaiqiang徐生韦赞同了此回答
容器和微服务是紧密集合在一起的,因为微服务会将单体应用拆分成很多小的应用,因而运维和持续集成会工作量变大,而容器技术能很好的解决这个问题 ,使得服务可以切割得更小,成为支撑微服务很好的平台。但是中小银行在微服务起步阶段,从技术架构角度以及运维角度都是一个全新的调...显示全部

容器和微服务是紧密集合在一起的,因为微服务会将单体应用拆分成很多小的应用,因而运维和持续集成会工作量变大,而容器技术能很好的解决这个问题 ,使得服务可以切割得更小,成为支撑微服务很好的平台。但是中小银行在微服务起步阶段,从技术架构角度以及运维角度都是一个全新的调整,所以建议在初期就开始容器化,也算是试验阶段。都后续团队技术沉淀后可大面积实施。

收起
 2019-10-24
浏览806
aixchina 邀答
jason2006xujason2006xu  技术经理 , 昆仑银行
老同志lawsoyinxin赞同了此回答
企业做微服务很有必要容器化。1、企业短期内某些原因企业不会实施Devops,但是为了提高开发、测试以及运维之间的效率中长期必须实施devops。2、DevOps 主要用于开发、测试以及运维之间的协作管理,并且通过自动化流程,更加快捷、频繁、易重复且可靠的构建软件、测试及发布部...显示全部

企业做微服务很有必要容器化。
1、企业短期内某些原因企业不会实施Devops,但是为了提高开发、测试以及运维之间的效率中长期必须实施devops。
2、DevOps 主要用于开发、测试以及运维之间的协作管理,并且通过自动化流程,更加快捷、频繁、易重复且可靠的构建软件、测试及发布部署。
3、在容器没有出现之前也有 DevOps,并且发展了这么多年,企业常用的做法是通过自动化脚本去实现配置引擎,例如:Puppet、Chef、Ansible 等工具。
4、基于以上工具来实践 DevOps,为什么没有使得 DevOps 发展起来,而且在企业中落地艰难。除了脚本缺陷外主要体现在:
人员强依赖;
不具备收敛;
非标准;
不具备回退等。
5、为什么说容器技术恰恰能克服这些阻力呢。第一,开发使用简单,因为在开发的时候不需要关注这个机器还有运行环境是什么,而能更加清晰的规划开发和运维的界面。
第二、抽象层次足够高,解耦彻底,而且容器是行业通用的标准,DevOps 发展那么多年,为什么说它没有流行起来,
比如说刚才提到实现 DevOps 平台多种技术多种工具,这些工具的标准搬到其他的公司它未必适用,不同公司的文化也不一样。
容器标准的生命力特别强,容器可以让 DevOps 普及发展以及流行,并且走出阴霾,证明 DevOps 的先进性,也确实是可以落地的。

收起
 2天前
我爱大锅饭我爱大锅饭  系统运维工程师 , 银行
yinxin彬彬赞同了此回答
个人浅见,供参考:这个问题我觉得要分2步来看,第一,要不要搞微服务拆分;第二点才是以何种技术实现微服务。微服务化是一种设计理念和架构,容器是一种微服务实现技术。微服务化出现的背景有两点:一是大型应用遇到性能问题(并发处理能力不足、数据库成为集中的性能瓶颈····),二是...显示全部

个人浅见,供参考:
这个问题我觉得要分2步来看,第一,要不要搞微服务拆分;第二点才是以何种技术实现微服务。微服务化是一种设计理念和架构,容器是一种微服务实现技术。微服务化出现的背景有两点:一是大型应用遇到性能问题(并发处理能力不足、数据库成为集中的性能瓶颈····),二是大型团队的合作问题(一个大型团队一起开发一个工程,效率低下),我个人认为团队协作的问题是微服务化的主要原因。所以回到您的问题本身,是否贵行的全部、某类应用真的已经要到了非微服务化不可的地步,如果是,那么首先要考虑的是对原有的应用要做何种拆分,拆分后的微服务规模多大,拆分出的微服务对现有的发布、运维团队带来多大的冲击。如果说原来的应用拆分完之后也就变为10个以内的微服务,那么借助一些自动化运维工具也可以搞的定,毕竟使用容器也是有额外的成本的(应用去状态化、应用日志改造、排错习惯、容器调度机制设计····)。但是如果一旦拆分后的微服务规模达到一定量级(现有开发、测试、运维团队安装原来的工作模式已经行不通了)且拆分之后的微服务版本迭代频次、并发能力、弹性扩容要求较高,那么我个人认为容器的确是最佳的选择。

收起
 3天前
浏览122
dean25dean25  软件架构设计师 , 民生银行
yinxinitjava赞同了此回答
从我们行实践的结果看,是有必要的。没有容器技术,微服务落地是非常困难的,仅仅是资源管理就会及其复杂,更别提调度和编排了。当然,建设容器技术也是一个庞大的工程,不仅需要K8S+Docker,还需要匹配的自动化发布系统、监控系统、日志系统、运维管理系统等。...显示全部

从我们行实践的结果看,是有必要的。没有容器技术,微服务落地是非常困难的,仅仅是资源管理就会及其复杂,更别提调度和编排了。当然,建设容器技术也是一个庞大的工程,不仅需要K8S+Docker,还需要匹配的自动化发布系统、监控系统、日志系统、运维管理系统等。

收起
 3天前
浏览152
aixchina 邀答
michael1983michael1983  技术经理 , 某证券
yinxinzhuhaiqiang赞同了此回答
那倒不尽然,只不过容器是微服务实现的最好工具和途径而已。显示全部

那倒不尽然,只不过容器是微服务实现的最好工具和途径而已。

收起
 2019-10-24
浏览761
杨文云杨文云  数据库管理员 , GBS
yinxin赞同了此回答
一般微服务和容器化都是一起做的因为微服务本身数量大又复杂,容器和容器编排可以解决很多流量管理、监控、资源管理等问题但根据各个微服务特性来决定,并不是都有这个必要。个人总结的原因如下:1)容器化的主要目的是方便管理,但是容器化本身是会带来性能的降低,一般不会存在一...显示全部

一般微服务和容器化都是一起做的因为微服务本身数量大又复杂,容器和容器编排可以解决很多流量管理、监控、资源管理等问题但根据各个微服务特性来决定,并不是都有这个必要。个人总结的原因如下:
1)容器化的主要目的是方便管理,但是容器化本身是会带来性能的降低,一般不会存在一个主机上跑一个容器的情况。
2)对于一些数据流量较大的服务,对性能要求较高的服务并不适合在容器内去运行
3)对整个容器化的掌握和理解需要一个团队,要不然技术债会背太多,没有一个稳定的团队做技术支持,不提倡全面的微服务有必要一定要容器化 ,如果没有团队维护,后期出的问题会更多。

收起
 2天前
lyc19820lyc19820  软件开发工程师 , 苏州博纳讯动软件有限公司
yinxin赞同了此回答
应用做了微服务以后, 能够实现快速开发迭代,但随之带来的问题是测试和运维部署的成本的提升 。容器化的环境能帮助我们进行这样的解决方案,目前看来他是最成熟和可靠的方式,当然也可能存在其他的方式,但是这个是被BATJ等各大公司采用且成功落地的方案。。简单说明一下:第一,应用...显示全部

应用做了微服务以后, 能够实现快速开发迭代,但随之带来的问题是测试和运维部署的成本的提升
。容器化的环境能帮助我们进行这样的解决方案,目前看来他是最成熟和可靠的方式,当然也可能存在其他的方式,但是这个是被BATJ等各大公司采用且成功落地的方案。。
简单说明一下:
第一,应用做了微服务拆分后,需要进行多个服务以及多个版本的的打包,测试,上线的量级信息大量增加,自动化部署操作需求明显增加
第二,如果需要服务器的扩容,需要进行环境的初始化,与原先的环境一致。部署工作繁重。

Docker容器可以完美的解决这个问题。
当然容器技术不是万能的,但是他是最合适做微服务的一个技术!

收起
 2019-11-07
浏览180

提问者

Jerry.Duna研发工程师, 江苏江南农村商业银行

问题状态

  • 发布时间:2019-10-24
  • 关注会员:15 人
  • 问题浏览:3264
  • 最近回答:2天前
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30