如何把握基于传统业务的微服务化和容器化时划分的粒度？

因运营商对业务的稳定性和连续性有比较高的要求，故容器化和微服化的演进路径必然是从边缘业务到核心业务，从简单应用到复杂应用，过于简单、并发度低的系统其实不必要作微服务化。同时相对一般的企业，运营商的硬件投入更大，服务器性能更性。过小过细的微服化不利于发挥硬件性能。容器化并非包治百病的良药，某些对并发吞吐量要求更高的业务，直接运行在裸机上，通过系统调优提高性能，容器化未必是最好的选择。
故如何在运营商容器化和微服化过程中，更好地把握划分的最小粒度是运营商容器化和微服务的一个重要问题。
个人认为至少有以下原则：
1、高并发，多业务聚合的应该坚决拆成容器化、微服务。而低并发，业务相对单一的不需要；
2、高I/O,如文件转移服务的不需要；
3、允分考虑主机性能，以保证业务吞吐量为第一原则来考虑拆分的必要性的粒度。