中小银行开展微服务改造的可行性和实施要点分析
体量不大的城商行，是否需要考虑微服务架构？传统的小型多法人银行系统，是否可以采用微服务？什么样的情况下才应该做维服务改造？
城商行如决定建设微服务，应如何进行？会否影响组织架构和运营模式大的调整？中小银行做微服务是否一定要容器化？
以下分享来自一些实践专家和正在探索的同行，供大家参考。1、城商行开展微服务改造的现状及可行性？
【问题描述】作为体量不是很大的城商行，单体应用可以满足当前以及未来几年的业务发展需要，但作为比较新的技术，又需要多了解，多探索，平衡。因为微服务改造，前期投入较大，开发投入和基础环境的投入都比较大，但前期的投入产出比会比较低，如何在这两者之间进行权衡。当前四大行和股份制银行基本都在探索应用微服务，普通城商行的微服务应用现状如何？
@尘世随缘 上海某互联网金融公司 技术总监：
据了解，目前城商行，或者农商行的的用户体量都比较小，系统迭代频率也比较低。所以小体量规模的系统不建议使用微服务架构。推荐在产品开发、设计过程中考虑全面点，如发现性能问题也可以采用增加硬件配置来解决。
2、对于传统的小型多法人银行系统，是否可以采用微服务？
【问题描述】我们是一家传统的小型多法人银行系统，使用的是传统的综合业务系统，现有系统已有10多年历史了，最近在思考，如果改造。向哪个方向改造，是否可以采用微服务化，是否有必要微服务化，带来的好处是什么？
@尘世随缘 上海某互联网金融公司 技术总监：
微服务是一把双刃剑，用的好能提高效率，用的不好会比现有单体系统更差。如果你目前的系统没有性能问题或者变更频率不高，那没有必要进行微服务的改造。单体一样能做到高性能。
@gavin_zhang 某股份制银行 系统架构师：
很多大拿一再强调，微服务不是包治百病的良药。微服务的目的是为了更快的响应需求和更好的水平扩展能力，如果不是特别看中这两点，采用基于开放服务的单体应用，可能会更合适。
3、什么样的情况下应该做微服务改造？
@尘世随缘 上海某互联网金融公司 技术总监：
1、代码冲突加剧
多个人或者一个团队一起维护一个模块，共同开发。当提交代码的时候发现大量冲突，每次提测或者发版的时候需要花大量的时间来解决冲突。随着团队规模的增大以及项目复杂程度增加，代码冲突的现象越严重；
2、模块耦合严重
模块之间通过接口或者DB相互依赖，耦合越来越严重。而且不同的人，写代码的风格不一样，代码质量也不一样，上线前需要协调多个团队，任何小模块的异常都会导致整个项目发布失败；
3、项目质量下降
由于所有的代码都是在一个服务里面，做一次改动，可能会牵一发而动全身，代码冲突以及耦合严重，导致测试覆盖范围不充分，经常会出现没有更改的模块在线上突然出现问题，查询后发现是由于工程师不小心做了某种改动，但是测试用例并没有覆盖；
4、团队效率下降
由于大量时间在处理代码冲突，消耗了研发人员大量的时间；而测试人员为了提高项目质量，不得不在每次发版之前做全方位的回归测试，本身一次小的迭代结果项目时间却很长；
如果上述的“痛”深深刺痛到了你，那么是时候开始做服务化改造了。
（参考文章《某互联网金融企业如何从0到4500W用户将单体应用迁移到微服务？》）
4、在准备、人力、投资三方面，城商行微服务建设该如何进行？
【问题描述】微服务敏捷、高效的迭代对银行传统平台架构带来巨大的冲击，在面向互联网金融快速的产品推广的背景下，中小规模的城商行也想进行微服务的IT系统重构。假设在资金和人力充足的前提下，从平台化到微服务的转型该如何进行，需要进行哪些环节的准备？微服务架构下，对人力的要求主要包括哪些？是否需要配套的IT管理和组织架构？以1000亿资产规模的银行，进行微服务转型，投资如何进行核算？
@尘世随缘 上海某互联网金融公司 技术总监：
微服务改造之前需要明确团队到底有没有痛点？如果仅仅是去探索微服务，那么没有必要展开微服务改造，团队内部学习即可。那么在决定实施微服务得时候，首先从高层就需要有这个意识，然后人员的配备，有微服务经验的架构师，以及人员的培训，实施部署方案的改造。最后是服务的拆分。千亿资产和微服务改造其实没有联系的，重点确认是否真的需要微服务改造。
@Steven99 软件架构设计师：
这个问题可能不是几句话能够说明白的，涉及微服务转型的规划、评估、实施、改进、组织调整等问题，每个问题都不容易。
首先要采用微服务或者进行微服务化转型，支撑微服务的平台是首先要考虑建设的。微服务管理治理平台的建设就是一个不小的工作量和投入。如果另外要引入云平台或者容器云平台，会更复杂化。
第二是微服务的业务流程梳理，提取公共微服务组件。如何入手微服务对于没有丰富经验的人员来说可能需要付出很多学习代价，也不是一年半载能够完成的。不建议一上来就去微服务，这个阶段可以认真深入学习和思考，把涉及的问题都想明白，再着手做。
第三才是微服务工具和框架选择，DevOps建设，组织调整以适应业务微服务化转型。
第四微服务化的发展是企业中台服务的建设，包括技术组件服务、数据服务、业务服务等，然后用这些服务构建业务应用。而这些业务应用正是目前在用的单体系统的升级品。
微服务架构下，对不同的人力要求不一样，如果服务能够做的比较好，对前端应用开发人员要求将降低，使用存在的微服务可以快速构建应用，实现敏捷交付，快速响应。如果做不好，会让自己陷入泥潭。微服务管理治理是一个非常重要、非常关键的工作，所以微服务支撑平台必须建设到位。
组织架构的调整并不容易，这个需要根据实际进行，可以微调，也可以大调，关键在于DevOps的建设要适应不同的组织架构。这是难点，不过不是不可以做。
资产规模是一回事，IT投入是一回事。对银行等金融行业来说，IT是工具，工具虽然有好坏，但目前还没有质的差别。而微服务架构只是一种分布式应用实现方式，既不是必须，也不是唯一。如果没有深入的了解，不建议轻易涉足微服务。
@lionor 某银行：
首先，IT重构的目的是什么？为了使用微服务重构全部系统还是解决部分系统的扩展性？
以前者来说，考虑的首要问题是规划：如何引入微服务框架；基于微服务框架，如何统筹开发运维测试基础设施；在技术架构的规划方面，已有的系统怎么管理，哪些需要做架构例外。
第二步，对业务的梳理上。微服务或者面向服务，服务整合是基本的，怎么识别服务，怎么根据流程抽取编排。需要有专门的团队进行。
第三：开发模式上，在确定微服务框架后，基于原型开发的模式基本不再适用，管理服务的团队需要指导开发人员，相对成本比基于原型开发增加至少50%。
5、微服务架构的应用是否会引起银行科技部门组织架构的调整和运维管理模式的调整？
@尘世随缘 上海某互联网金融公司 技术总监：
微服务架构不仅仅是技术的架构演变，也是人员组织架构的演变过程，因为需要有高层来推动整个架构的改进，同时人员也需要做结构调整，每个人负责的领域，模块的调整。
@liufengyi 软件架构设计师：
微服务架构在实践中必然触及组织架构架构调整和管理模式的调整，构建微服务体系，需要整个配套设施的支持(变更流程，监控，资源管理，测试，版本管理，服务注册与发现，配置管理，日志，服务治理)涉及方方面面。
6、中小银行做微服务有必要一定要容器化吗?？
@yujin2010good 大型零售巨头 系统工程师：
微服务和容器化是非常紧密关系，不是必须关系，如果微服务规模较小，不如3-5个，且并发不大，或者短期内并发变化不大，做与不做看心情。
如果说规模很大，比如一个项目有50个微服务，平均每个微服务至少部署4个，这就是200，且并发变化较大，这样使用容器就能快速部署，自动扩容和缩容。
开发和测试来说也能快速测试，迭代。
其实我觉得还是根据公司业务的特点来选择，当然如果条件成熟，微服务和容器并进比较好，当然也要看应用类型，有些传统的应用也不太适合。（比如需要key的，不能宕机，自动启动一个的）
@gavin_zhang 某股份制银行 系统架构师：
前提是微服务的规模有多大。
中大规模的系统：从目前的技术趋势和以往的实践来看，微服务和容器化部署还是结合比较紧密的。微服务系统一旦上了规模，成千上万个服务实例的运维是一个很大的挑战。容器和容器编排正是解决多服务和多实例的部署，维护，流量控制等问题的解决方案。而且是目前来说最好的解决方案。
小系统（小于50个服务实例）可以考虑用自动化部署工具支持。
@yeefone 某大型保险公司 技术经理：
不一定。可以尝试在部分业务上尝试容器化，积累经验，具体要看使用方的技术积累和团队能力，不易过早过快的推进容器化。
@尘世随缘 上海某互联网金融公司 技术总监：
容器和微服务是紧密集合在一起的，因为微服务会将单体应用拆分成很多小的应用，因而运维和持续集成会工作量变大，而容器技术能很好的解决这个问题 ，使得服务可以切割得更小，成为支撑微服务很好的平台。但是中小银行在微服务起步阶段，从技术架构角度以及运维角度都是一个全新的调整，所以建议在初期就开始容器化，也算是试验阶段。都后续团队技术沉淀后可大面积实施。
@jason2006xu 昆仑银行 技术经理：
企业做微服务很有必要容器化。
1、企业短期内某些原因企业不会实施Devops，但是为了提高开发、测试以及运维之间的效率中长期必须实施devops。
2、DevOps 主要用于开发、测试以及运维之间的协作管理，并且通过自动化流程，更加快捷、频繁、易重复且可靠的构建软件、测试及发布部署。
3、在容器没有出现之前也有 DevOps，并且发展了这么多年，企业常用的做法是通过自动化脚本去实现配置引擎，例如：Puppet、Chef、Ansible 等工具。
4、基于以上工具来实践 DevOps，为什么没有使得 DevOps 发展起来，而且在企业中落地艰难。除了脚本缺陷外主要体现在：
人员强依赖；
不具备收敛；
非标准；
不具备回退等。
5、为什么说容器技术恰恰能克服这些阻力呢。第一，开发使用简单，因为在开发的时候不需要关注这个机器还有运行环境是什么，而能更加清晰的规划开发和运维的界面。
第二、抽象层次足够高，解耦彻底，而且容器是行业通用的标准，DevOps 发展那么多年，为什么说它没有流行起来，
比如说刚才提到实现 DevOps 平台多种技术多种工具，这些工具的标准搬到其他的公司它未必适用，不同公司的文化也不一样。
容器标准的生命力特别强，容器可以让 DevOps 普及发展以及流行，并且走出阴霾，证明 DevOps 的先进性，也确实是可以落地的。
@我爱大锅饭 银行 系统运维工程师：
个人浅见，供参考：
这个问题我觉得要分2步来看，第一，要不要搞微服务拆分；第二点才是以何种技术实现微服务。微服务化是一种设计理念和架构，容器是一种微服务实现技术。微服务化出现的背景有两点：一是大型应用遇到性能问题（并发处理能力不足、数据库成为集中的性能瓶颈····），二是大型团队的合作问题（一个大型团队一起开发一个工程，效率低下），我个人认为团队协作的问题是微服务化的主要原因。所以回到您的问题本身，是否贵行的全部、某类应用真的已经要到了非微服务化不可的地步，如果是，那么首先要考虑的是对原有的应用要做何种拆分，拆分后的微服务规模多大，拆分出的微服务对现有的发布、运维团队带来多大的冲击。如果说原来的应用拆分完之后也就变为10个以内的微服务，那么借助一些自动化运维工具也可以搞的定，毕竟使用容器也是有额外的成本的（应用去状态化、应用日志改造、排错习惯、容器调度机制设计····）。但是如果一旦拆分后的微服务规模达到一定量级（现有开发、测试、运维团队安装原来的工作模式已经行不通了）且拆分之后的微服务版本迭代频次、并发能力、弹性扩容要求较高，那么我个人认为容器的确是最佳的选择。
@dean25 民生银行 软件架构设计师：
从我们行实践的结果看，是有必要的。没有容器技术，微服务落地是非常困难的，仅仅是资源管理就会及其复杂，更别提调度和编排了。当然，建设容器技术也是一个庞大的工程，不仅需要K8S+Docker，还需要匹配的自动化发布系统、监控系统、日志系统、运维管理系统等。
@michael1983 某证券 技术经理：
那倒不尽然，只不过容器是微服务实现的最好工具和途径而已。
@杨文云 GBS 数据库管理员：
一般微服务和容器化都是一起做的因为微服务本身数量大又复杂，容器和容器编排可以解决很多流量管理、监控、资源管理等问题但根据各个微服务特性来决定，并不是都有这个必要。个人总结的原因如下：
1）容器化的主要目的是方便管理，但是容器化本身是会带来性能的降低，一般不会存在一个主机上跑一个容器的情况。
2）对于一些数据流量较大的服务，对性能要求较高的服务并不适合在容器内去运行
3）对整个容器化的掌握和理解需要一个团队,要不然技术债会背太多，没有一个稳定的团队做技术支持，不提倡全面的微服务有必要一定要容器化 ，如果没有团队维护，后期出的问题会更多。
@lyc19820 苏州博纳讯动软件有限公司 软件开发工程师：
应用做了微服务以后， 能够实现快速开发迭代，但随之带来的问题是测试和运维部署的成本的提升。容器化的环境能帮助我们进行这样的解决方案，目前看来他是最成熟和可靠的方式，当然也可能存在其他的方式，但是这个是被BATJ等各大公司采用且成功落地的方案。
简单说明一下：
第一，应用做了微服务拆分后，需要进行多个服务以及多个版本的的打包，测试，上线的量级信息大量增加，自动化部署操作需求明显增加。
第二，如果需要服务器的扩容，需要进行环境的初始化，与原先的环境一致。部署工作繁重。
Docker容器可以完美的解决这个问题。
当然容器技术不是万能的，但是它是最合适做微服务的一个技术！
@尹学峰 Rancher企业级Kubernetes管理平台 售前技术支持：
首先，需要明确的是微服务化和容器化是应用架构演进的二个方向，二者没有必然关系，也就是说，可以做一个不依赖容器技术的微服务，也可以制作一个单体的容器化应用。
但是，更需要强调的是容器技术是实践微服务理念的最好的承载。如果想把微服务理念的价值充分发挥出来，那么，就必须做容器化。打个比方：
容器镜像(image)就好比程序领域的类(class)
而运行状态下的容器(container)就好比一个一个的实例(instance)
不同的实例组合到一起，形成一个有机的整体，对外提供服务
不知您是否理解我想表达的意思。
@狄俄尼索斯 UProject 软件架构设计师：
这两者没有耦合关系，是解耦的。
微服务改造涉及的是业务开发人员与架构师；容器属于基础设施，运维团队关注的。
理想情况开发人员不关注微服务是运行在容器内还是在虚拟机内的。
@liufengyi 某互联网银行 软件架构设计师：
微服务与容器的关系是比较密切的，微服务运行实体其实是进程-服务，恰好与容器的单进程模型吻合，再加上容器能保证环境的一致性，加速部署效率，能有效的减轻运维成本，因此容器化是微服务的一个比较好的实践。
@nameless 某云计算厂商 技术总监：
不一定，容器只是工具，从最佳实践来说容器和微服务比较切合。
技术选型，工具选择，一般从适合自己的角度出发，多个维度进行比较。
有些技术比较先进，但不一定适合自己，选择适合自己的最重要。
如有任何问题，可点击文末阅读原文，到社区提问 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 “微服务”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/95163
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场