本文首发胖波聊架构界，微信公众号：xiaobo2as
本文概要
导言
开发团队和大家一起踩过了无数的坑，最终打造了今天的DSF2.0平台。回顾爬坑记录，现整理一些爬坑心得体验供大家参考，也斗胆提出一些最佳实践以抛砖引玉。
按照康威定律的说法，组织结构一定会反映到系统架构上，同程是树形结构+底层网状结构，那么服务之间一定是每个系统的架构呈明显的树状，但是系统之间会有多重的服务互访。
微服务设计要充分考虑哪些是自用（inner），外部访问（outer）和混用（mix）服务，并尽可以能将其迁移对应的服务组里。
新老项目由于处于生命周期的不同阶段，修改和发布频率会有很大差别。应该尽量将处于生命周期中不同阶段的接口分割，避免高频更新服务和低频更新服务捆绑，避免向稳定运行的服务组添加新业务接口，而是应该考虑在新的服务组中实现。
服务组中的不同服务调用频率会有巨大差别，而高频调用肯定会占据更多的资源，会出现个别接口耗尽资源导致同组接口一起失败（资源竞争），需要对高频访问的服务设置定制的运行策略，如分配更多的CPU核心数和内存， 调整部署使其尽可能靠近数据源等策略，但是如果将所有服务宿主都做成高配，会造成巨大的资源浪费事实上也没有必要，所以应该将高低频访问的服务分割以使其能为获得更好的性能和可靠性做针对性优化。
上一维度其实已经涵盖了读写分离的一部分，但是为了突出读写分离的必要性，这里单独列出。一般数据操作模式分为CQRS和CRUD两种模式，各有优缺点。
从操作是否对数据本身造成影响来看，可以粗略的分为读写两类 ， 一般来说写操作的频率会大大低于读操作，写操作经常会有更严格的认证授权机制，一般为内部（inner）调用。这些和读操作都有巨大差异性， 因此建议流量较大或较为核心的服务应该做读写分离，分拆为两个服务组发布。
最后分享一个粒度控制的小技巧，大多数情况出现在系统里的每个名词都会在存储层面拥有一席之地，对应一个独立的数据表或库，所以系统里出现的名词都可能是一个潜在的微服务。
具体参见 语义化版本 2.0.0 。使用标准的语义化版本能使大家保证对版本有统一的理解，应尽量避免自行定义版本语义。DSF 版本推荐使用SemVer 约定，略有不同的是DSF推荐四位版本号（1.2.3.4），前两位作为主版本（1.2）， SemVer版本一般为三位（x.y.z 对应：主版本号.次版本号.修订号）。
当一个团队选择微服务作为服务化实施平台时必须明确微服务化有一个较高的门槛，需要团队自身已经是一个较为成熟运作体系，例如有实施前有完善的架构设计，团队成员有明确的职责划分，团队成员对服务内聚和服务耦合有明确的认知。
上述的这些方面都会促成一个结果： 使设计开发的服务接口最终具有良好的抽象并体现出规划性，最终能够在服务实施前就能交付有良好兼容性的服务契约。实践中体现为一个版本迭代新增、修改、删除的任何部分都是经过慎重思考并体现在服务契约里，实际开发不轻易的修改和增添服务接口。
