1.从哪些角度考虑拆分微服务？
    业务功能：从业务上讲，功能是有密切的联系，还是相对独立
    变更频次：不同的功能变更频次不同，是否通过拆分使部署频次接近功能变更频次
    可伸缩性与吞吐量：不同的功能对容器弹性需求不同，是否通过拆分达到合理分配弹性
    容错：微服务可以避免大单体一挂全挂的问题，需思考拆分后的容错特性
    安全性：是否需要通过拆分，对不同微服务施加不同安全策略
    2.从哪些角度考虑合并微服务？
    数据一致性：拆分微服务必然导致数据一致性问题，如果一致性要求总体较高，思考业务是否是耦合的
    数据依赖：如果功能的数据依赖于其他的功能，考虑这个计算处理数据的服务是否是别的业务的一部分
    工作流与编排：对业务的工作流程顺序的考虑，具体是思考服务间调用和依赖的链路的情况
    3.微服务划分有哪些原则：
    按业务边界划分：依据业务边界（非技术维度）拆分或按DDD方法（上下文边界、聚合边界）拆分
    按组织结构划分：依据康威定律拆分或按研发人员规模拆分，一个服务的开发组规模不能过大
    按业务变更频率拆分：变更频率相差较大，可拆不同的微服务
    按技术栈划分：如web服务用Java、AI服务用Python，可以拆分
    按非功能需求拆分：对业务健壮性、安全性、可扩展性的不同要求做拆分
    4.基本思想和产生架构步骤：
    软件架构中的所有东西，都是一种权衡
    业务价值驱动架构决策
    展开来说：遇到需要架构设计的地方不要直接扎进一个预设的具体解决方案，应该先思考面对了什么问题。列出解决方案的列表，分析每个方案的优势和劣势。最终用产生的业务价值驱动架构决策。比如某个方案缩短延时，要思考延时在这个业务系统中是不是有重要的业务价值。
    *本文内容来自对tw的钱平老师分享内容的记录