争议 | 中小银行做微服务有必要一定要容器化吗?
中小银行做微服务有必要一定要容器化吗？
现在中小银行都在往微服务化这个方向去更新迭代自己的业务及技术架构，企业做微服务有必要一定要容器化吗？ （来自社区探讨，问题来自@Jerry.Duna 江苏江南农村商业银行 研发工程师）
“很有必要”
“初期就应开始容器化”
↓↓↓
@dean25 民生银行 软件架构设计师：
从我们行实践的结果看，是有必要的。没有容器技术，微服务落地是非常困难的，仅仅是资源管理就会及其复杂，更别提调度和编排了。当然，建设容器技术也是一个庞大的工程，不仅需要K8S+Docker，还需要匹配的自动化发布系统、监控系统、日志系统、运维管理系统等。
@jason2006xu 昆仑银行 技术经理：
企业做微服务很有必要容器化。
1、企业短期内某些原因企业不会实施Devops，但是为了提高开发、测试以及运维之间的效率中长期必须实施devops。
2、DevOps 主要用于开发、测试以及运维之间的协作管理，并且通过自动化流程，更加快捷、频繁、易重复且可靠的构建软件、测试及发布部署。
3、在容器没有出现之前也有 DevOps，并且发展了这么多年，企业常用的做法是通过自动化脚本去实现配置引擎，例如：Puppet、Chef、Ansible 等工具。
4、基于以上工具来实践 DevOps，为什么没有使得 DevOps 发展起来，而且在企业中落地艰难。除了脚本缺陷外主要体现在：人员强依赖；不具备收敛；非标准；不具备回退等。
5、为什么说容器技术恰恰能克服这些阻力呢？
第一，开发使用简单，因为在开发的时候不需要关注这个机器还有运行环境是什么，而能更加清晰的规划开发和运维的界面。
第二、抽象层次足够高，解耦彻底，而且容器是行业通用的标准，DevOps 发展那么多年，为什么说它没有流行起来，
比如说刚才提到实现 DevOps 平台多种技术多种工具，这些工具的标准搬到其他的公司它未必适用，不同公司的文化也不一样。
容器标准的生命力特别强，容器可以让 DevOps 普及发展以及流行，并且走出阴霾，证明 DevOps 的先进性，也确实是可以落地的。
@尘世随缘 技术总监：
容器和微服务是紧密集合在一起的，因为微服务会将单体应用拆分成很多小的应用，因而运维和持续集成会工作量变大，而容器技术能很好的解决这个问题 ，使得服务可以切割得更小，成为支撑微服务很好的平台。但是中小银行在微服务起步阶段，从技术架构角度以及运维角度都是一个全新的调整，所以建议在初期就开始容器化，也算是试验阶段。等后续团队技术沉淀后可大面积实施。
“没必要”
“不宜过早过快的推进容器化”
↓↓↓
@yeefone 某大型保险公司 技术经理：
不一定。可以尝试在部分业务上尝试容器化，积累经验，具体要看使用方的技术积累和团队能力，不宜过早过快的推进容器化。
@杨文云 数据库管理员：
一般微服务和容器化都是一起做的，因为微服务本身数量大又复杂，容器和容器编排可以解决很多流量管理、监控、资源管理等问题，但根据各个微服务特性来决定，并不是都有这个必要。个人总结的原因如下：
1）容器化的主要目的是方便管理，但是容器化本身是会带来性能的降低，一般不会存在一个主机上跑一个容器的情况。
2）对于一些数据流量较大的服务，对性能要求较高的服务并不适合在容器内去运行。
3）对整个容器化的掌握和理解需要一个团队，要不然技术债会背太多，没有一个稳定的团队做技术支持，不提倡全面的微服务有必要一定要容器化 ，如果没有团队维护，后期出的问题会更多。
@狄俄尼索斯 软件架构设计师 ：
这两者没有耦合关系，是解耦的。
微服务改造涉及的是业务开发人员与架构师；容器属于基础设施，运维团队关注的。
理想情况开发人员不关注微服务是运行在容器内还是在虚拟机内的。
“不一定，但比较切合”
“容器是实践微服务理念最好的承载”
↓↓↓
@liufengyi 某互联网银行 软件架构设计师：
@lyc19820 软件开发工程师：
应用做了微服务以后， 能够实现快速开发迭代，但随之带来的问题是测试和运维部署的成本的提升。容器化的环境能帮助我们进行这样的解决方案，目前看来他是最成熟和可靠的方式，当然也可能存在其他的方式，但是这个是被BATJ等各大公司采用且成功落地的方案。
简单说明一下：
第一，应用做了微服务拆分后，需要进行多个服务以及多个版本的的打包，测试，上线的量级信息大量增加，自动化部署操作需求明显增加
第二，如果需要服务器的扩容，需要进行环境的初始化，与原先的环境一致。部署工作繁重。
Docker容器可以完美的解决这个问题。
当然容器技术不是万能的，但是它是最合适做微服务的一个技术！
@nameless 某云计算厂商 技术总监：
不一定，容器只是工具，从最佳实践来说容器和微服务比较切合。
技术选型，工具选择，一般从适合自己的角度出发，多个维度进行比较。有些技术比较先进，但不一定适合自己，选择适合自己的最重要。
@1983michael1983 某证券 技术经理：
那倒不尽然，只不过容器是微服务实现的最好工具和途径而已。
@尹学峰 售前技术支持：
首先，需要明确的是微服务化和容器化是应用架构演进的二个方向，二者没有必然关系，也就是说，可以做一个不依赖容器技术的微服务，也可以制作一个单体的容器化应用。
但是，更需要强调的是容器技术是实践微服务理念的最好的承载。如果想把微服务理念的价值充分发挥出来，那么，就必须做容器化。打个比方：
容器镜像(image)就好比程序领域的类(class)
而运行状态下的容器(container)就好比一个一个的实例(instance)
不同的实例组合到一起，形成一个有机的整体，对外提供服务
不知您是否理解我想表达的意思。
“前提是微服务的规模有多大”、
“是否全部、某类应用非微服务化不可”
↓↓↓
@gavin_zhang 某股份制银行 系统架构师：
前提是微服务的规模有多大。
中大规模的系统：从目前的技术趋势和以往的实践来看，微服务和容器化部署还是结合比较紧密的。微服务系统一旦上了规模，成千上万个服务实例的运维是一个很大的挑战。容器和容器编排正是解决多服务和多实例的部署，维护，流量控制等问题的解决方案。而且是目前来说最好的解决方案。
小系统（小于50个服务实例）可以考虑用自动化部署工具支持。
微服务和容器化是非常紧密关系，不是必须关系，如果微服务规模较小，比如3-5个，且并发不大，或者短期内并发变化不大，做与不做看心情。
如果说规模很大，比如一个项目有50个微服务，平均每个微服务至少部署4个，这就是200，且并发变化较大，这样使用容器就能快速部署，自动扩容和缩容。
开发和测试来说也能快速测试，迭代。
其实我觉得还是根据公司业务的特点来选择，当然如果条件成熟，微服务和容器并进比较好，当然也要看应用类型，有些传统的应用也不太适合。（比如需要key的，不能宕机，自动启动一个的）
@我爱大锅饭 银行 系统运维工程师：
个人浅见，供参考：
这个问题我觉得要分2步来看。第一，要不要搞微服务拆分；第二点才是以何种技术实现微服务。微服务化是一种设计理念和架构，容器是一种微服务实现技术。微服务化出现的背景有两点：一是大型应用遇到性能问题（并发处理能力不足、数据库成为集中的性能瓶颈……），二是大型团队的合作问题（一个大型团队一起开发一个工程，效率低下），我个人认为团队协作的问题是微服务化的主要原因。
所以回到您的问题本身，是否贵行的全部、某类应用真的已经要到了非微服务化不可的地步，如果是，那么首先要考虑的是对原有的应用要做何种拆分，拆分后的微服务规模多大，拆分出的微服务对现有的发布、运维团队带来多大的冲击。如果说原来的应用拆分完之后也就变为10个以内的微服务，那么借助一些自动化运维工具也可以搞的定，毕竟使用容器也是有额外的成本的（应用去状态化、应用日志改造、排错习惯、容器调度机制设计……）。但是如果一旦拆分后的微服务规模达到一定量级（现有开发、测试、运维团队安装原来的工作模式已经行不通了）且拆分之后的微服务版本迭代频次、并发能力、弹性扩容要求较高，那么我个人认为容器的确是最佳的选择。
以上是社区会员的一些探讨，非常期待您来分享观点 欢迎点击文末阅读原文到社区讨论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 “微服务”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/95163
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场