复杂应用的微服务拆分原则是什么？拆分后如何编排，是否引入柔性框架 ？

业内建议的拆分原则：(从业务角度)
功能完整性、职责单一性；
粒度适中，团队可接受；
不断更新迭代；
API的版本兼容性优先考虑；

另外，在项目一开始的时候不要认为微服务一蹴而就，它是随着业务的演进不断变化和演进的。

微服务是相对单体架构的，拆分之前需要考虑清楚业务是否一定要微服务化，上了微服务并不一定比单体架构好，最好是结合业务需求，以及团队现状综合考量。

拆分之后如何编排？可以参考k8s的编排方式，yaml方式也可以

至于是否引入柔性框架，可以参考业务特性是否适合。

拆分的大原则还是高内聚、低耦合。高内聚的功能可以放到一个微服务里。另外一个原则是支持RPC通信，或者具备RPC通信条件的模块可以拆分出来作为微服务。拆分以后，可以通过helm来编排应用。此外，有些服务之间不可避免会有依赖关系，需要在应用层面或者使用K8S的initContianer来做服务探测，确保不按顺序启动的情况下也不影响整体应用

业界通常的原则是：
单一职责
服务粒度适中
考虑团队结构
以业务模型切入
演进式拆分
避免环形依赖和双向依赖