得益于nginx等反向代理的流行以及metrics/endpoit规范的成熟。微服务的理念开始流行了。 但是微服务究竟要多"微"才合适？以下是我的个人实践。
不能按接口分:
这样的粒度太细.比如新增订单/查询订单分为两个microservice,优点是可以根据各自的负载合理分配服务器 资源。缺点是microservice数量过多，这样拆分的话，至少存在几十个service，这样对service的依赖关系，监控 ／部署都增加很大的难度。
不能按数据库表名(table)分:
这是个鲁莽的做法。很明显，数据库的的事务处理将极为棘手。
不能按数据库名(db)分:
这样的粒度太粗.好处是本地数据库数据一致性问题很好解决。缺点是功能过于集中，不利于后期改进。
建议按子业务分，同时考虑数据库表的关联:
比如按订单/用户管理这样的粒度分，数据库表相对独立。这样service的数量较为合适，语意上也容易理解。
