在云原生架构应用的开发中，如何拆分微服务，微服务的粒度要做到多细一直都是架构师们所面临的问题。其实这个问题一直没有正确的答案，这里给出几个指导原则帮助大家在规划微服务的时候进行参考。
围绕业务域进行服务的建模
微服务拆分的目标并不是让你的服务尽可能的小，“微”服务名字具有误导性。构建一个服务所编写代码量并不是衡量一个服务大小的原则，代码写的多也不是服务会有错误的标志，有时候“重”一些的服务有必要的。
微服务的规划中，有一个“单一责任原则”：每个模块或者服务应该实现单个的功能。比如，一个服务对客户数据进行跟踪，并对他们进行CRUD操作。在《微服务原则》一书中指出，微服务应该围绕业务领域进行建模。围绕业务领域实现场景的简化，能够避免落入一个服务实现所有功能的陷阱。
高内聚
同样在业务领域的规划中同样也需要注意颗粒度，尤其是在企业应用场景中，企业应用中业务领域的关联度远比C端场景复杂，微服务划分的过细会对企业业务事务性和业务操作性能造成影响。这就是我们所说的过于分离的设计。所以在微服务的规划中，我们需要另一个原则的指导，就是高内聚原则，是指把相似和相关的业务放在一起，连接或融合共享内容、功能、原因或目标的部分，简单地说:不应该分割的业务就放在一个微服务当中。微服务架构最初的想法是让应用变得简单，但是过于分裂的服务会让应用流程变得更加复杂。
5个微服务设计原则
01
关注点聚焦原则
关注点聚焦意味着微服务只做一件事，只关注一个业务领域。
02
服务离散原则
微服务必须具有清晰的边界，具有很好的封装。结合聚焦原则，也指导了相关的业务操作需要进行的微服务封装参考。
03
可移植原则
微服务方便应用的迁移与扩展，因此微服务需要能够方便的实现在不同环境中的迁移。
04
数据所有权原则
微服务有自己的存储机制，与其他的微服务实现分离，通过接口来进行交互。对于企业应用来说，微服务的数据所有权同样需要针对业务领域进行划分，企业业务数据的整合与关联也会决定微服务在依据数据所有权进行判别时进行服务的规划。
05
短时原则
微服务的运行通常是短暂的，快速创建、快速销毁，对于相关的服务和应用也只是短暂的影响，实现优雅的启动和关闭。长时运行的微服务则会破坏应用中这种微服务架构的灵活性和扩展性。
结论
以上是在规划与开发微服务应用时需要参考几个原则，将这些原则与我们业务实际场景进行结合，最终构建出符合企业业务需要的微服务架构应用。
