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

微服务改造是要投入的，因此首先要想清楚应用的负载特征是什么，微服务改造的目的是什么，是享受云中动态资源扩缩带来的便利，还是仅仅只是运维的便利？如果只是后者的话，做好单体应用的自动化运维也是可以的。
其次，从一个应用的非关键功能入手剥离，尽量要考虑两套模式能够并行，逐步将流量切换到微服务侧。等团队练熟手后，再逐步剥离关键功能。
最后，没有哪个应用是不能拆分的，除非不是自己写的。

微服务的好处有很多，但是在实际应用中，应用进行微服务改造主要出于几个方面考虑：一是降低各个系统之间的耦合，这样才可以让各个团队对自己负责的模块进行快速的迭代，快速满足业务需求；二是微服务改造后方便实现云上业务的弹性伸缩；三是微服务改造后，可以通过熔断机制来保证当有的应用模块出现问题时，主要业务流程不受影响，从而保证用户体验。那么如果对传统应用进行微服务改造，首先需要做到代码自主可控，只有代码自主可控你才能做业务逻辑或者模块的拆分，那么从这个角度看，外购的系统除非厂家配合，否则这块很难进行微服务改造；其次，要梳理清楚业务系统的重要等级，从重要等级低的系统来入手，毕竟团队进行微服务改造对开发而言也是需要一个转变的过程，从低优先级的系统进行改造，即使出了问题，也不至于造成太大影响。最后，还要考虑应用上云到什么程度，是只想快速用云上资源，还是要实现动态热扩容和缩容，不同的程度，对应用的改造也是不同的。

上微服务前要先考虑是否准备好了上微服务：
1 是否有自动化部署能力，手工部署成百上千的实例是不实际的。
2 持续集成工具和文化可以提高开发效率。
3 相对应的组织机构。
应用上云可以分为现有系统迁移和新系统。对于新系统可以通过持续重购的方式，不断拆分和归并服务，达到低偶合高内聚的目标。对于现有系统采用绞杀的方式，化整为零，最终实现微服务。

我觉得从两方面分析：

1. 新的应用在开发建设初期就向着微服务的方向进行。
2. 既有的应用如果是互联网应用，并且影响着其他新系统架构的实现，那么就要重新进行改造。