一、防止过度设计
微服务的拆分一定要结合团队人员规模来考虑，笔者就曾遇到过一个公司的项目，是从外部采购回来的，微服务划分为十几个应用，我们在此项目基础上进行自行维护和扩展。由于公司业务规模不大，而且二次开发的需求量比较小，负责这个项目的开发也就2个人，但是服务拆分的非常细，导致开发新的功能和查找生产问题时，工作量都非常大，效率非常的低，严重出现小马拉大车的情况，非常的吃力不讨好。借助笔者亲身经历，强烈建议不要一上来就直接各种微服务拆分，应该考虑项目的投入和后期维护成本，如果没那么的的资源就不要拆分过多的服务，微服务的数量和维护成本是有正比关系的，切记过渡设计。最好的方案应该是结合当下业务规模和人员情况，如果是试点业务，可以先单体项目开始做起，业务有增长的时候，项目再逐步进行细分拆解和增加研发人员，与业务规模成正比。
二、API接口调用的出入参
微服务之间的调用，接口的出入参是忌讳使用Map、Json等对象来封装，这样导致使用者根本没法快速的知道接口的入参和出参分别有哪些字段，并且操作参数的时候写错key的概率会提高。建议对出入催直接封装为普通的JavaBean对象，另外有一点需要特别注意，对出入参的对象封装建议做成一个jar包模块，这样其他服务调用的时候直接通过引入jar包，即可方便的操作出入催，也减少代码的重复率。当服务的接口有改动时，尽量遵循OCP原则（即尽量采用新增字段而不是删除原有字段，做向下兼容），并且可通过修改jar包版本来发布新的出入参依赖jar包，相关依赖服务方可根据需要进行更新依赖的jar包。
以上是笔者亲身经历过微服务后的反思和总结，有更好的建议和想法，可留言互相探讨。
