微服务架构

1. 架构好坏都是按达成架构设计结果来评估的，从最终如果你能够完全实现那样的架构设计，来评估系统的效果的，包括在那个结果状态后的业务响应、运维成本、等。
   所以，可以认为那是一种理想结果下的架构风格的高度！就如元数据驱动架构在解决开放定制问题方面的最终高度要远高于非元数据驱动架构。
2. 不同架构的实施难度不同，有时你可能根本走不到那个预期的结果，各种因素。
3. 一定要把时间周期和变化考虑进来，业务、技术、环境都不是静态的，要考虑在变化的环境下一种架构风格的实施方式！
4. 没有业务的输入是不可能做好微服务的【微服务的能力最终是用于业务的】，基于已有系统剥离&沉淀，或有足够深厚的领域&业务经验，xx相当于后者。
5. 即使有足够经验，也不能一开始就“分离独立的方式并行开发”，先按“单体应用”的方式形成初始版本，在逐个将可以覆盖80%以上领域能力的微服务“独立出来自治【独立开发、独立发布、独立部署】”。
6. 基于已有系统的情况，要先确定领域边界，然后划定主数据范围，继而构建领域能力，逐步把业务的调用分流到新的领域微服务上。过程中不断去收集对本领域主数据的访问请求，逐渐收回领域逻辑！
7. 领域内的抽象设计才是真正的难点！是微服务架构落地的关键！