来自社区交流

企业上云，应用如何进行微服务化？

在云的环境下，为了应用的快速迭代以及弹性扩容，传统的应用需要进行微服务改造，如果不能拆分，还是过重的单体应用，就不适合上云。

@wykkx 某基金公司

微服务的好处有很多，但是在实际应用中，应用进行微服务改造主要出于几个方面考虑：一是降低各个系统之间的耦合，这样才可以让各个团队对自己负责的模块进行快速的迭代，快速满足业务需求；二是微服务改造后方便实现云上业务的弹性伸缩；三是微服务改造后，可以通过熔断机制来保证当有的应用模块出现问题时，主要业务流程不受影响，从而保证用户体验。

那么如果对传统应用进行微服务改造，首先需要做到代码自主可控，只有代码自主可控你才能做业务逻辑或者模块的拆分，从这个角度看，外购的系统除非厂家配合，否则这块很难进行微服务改造；其次，要梳理清楚业务系统的重要等级，从重要等级低的系统来入手，毕竟团队进行微服务改造对开发而言也是需要一个转变的过程，从低优先级的系统进行改造，即使出了问题，也不至于造成太大影响。最后，还要考虑应用上云到什么程度，是只想快速用云上资源，还是要实现动态热扩容和缩容，不同的程度，对应用的改造也是不同的。

@王军 工行

微服务改造是要投入的，因此首先要想清楚应用的负载特征是什么，微服务改造的目的是什么，是享受云中动态资源扩缩带来的便利，还是仅仅只是运维的便利？如果只是后者的话，做好单体应用的自动化运维也是可以的。

其次，从一个应用的非关键功能入手剥离，尽量要考虑两套模式能够并行，逐步将流量切换到微服务侧。等团队练熟手后，再逐步剥离关键功能。

最后，没有哪个应用是不能拆分的，除非不是自己写的。

@赵海

我觉得从两方面分析：

新的应用在开发建设初期就向着微服务的方向进行。

既有的应用如果是互联网应用，并且影响着其他新系统架构的实现，那么就要重新进行改造。

@gavin_zhang 招行

上微服务前要先考虑是否准备好了上微服务：

1 是否有自动化部署能力，手工部署成百上千的实例是不实际的。

2 持续集成工具和文化可以提高开发效率。

3 相对应的组织机构。

应用上云可以分为现有系统迁移和新系统。对于新系统可以通过持续重购的方式，不断拆分和归并服务，达到低偶合高内聚的目标。对于现有系统采用绞杀的方式，化整为零，最终实现微服务。