1、在学习软件构造、设计相关知识时，大家应该有学习到内聚性的概念：即把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离开来。而
微服务将这个理念应用在独立的服务上。根据业务的边界来确定服务的边界，这样就很容 易确定某个功能代码应该放在哪里。
我个人觉得，微服务就是将原来的单体应用安装功能进行切分，然后各个服务之间通过通信 (跨进程、跨机器) 来共同完成原来的单体应用所提供的功能。微服务对比与原来的单体应用，有它的优势，如服务的自治性增强、但同时也会带来一些其他问题，如性能、复杂度等问题。
2、想要使用微服务，首先是要清楚哪些业务或者功能应该成为单独的服务。《微服务设计》一书中给了一些建议：
当你在思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下 文能够提供的功能来考虑。这个上下文是做什么用的。组织结构和软件架构会互相影响。
当然，书中列出的建议不止这些，我也想谈一谈我自己的一些想法。
我觉得首先要从业务出发(单独的基础服务，例如分布式事务、数据库同步服务例外)，这一块业务我们需要实现怎样的功能，它在系统中处于什么样的位置，它需要与哪些服务进行交互(提供接口和消费接口)。知道了业务功能在整个系统的位置，有助于我们进行决策。
其次，考虑业务极有可能的变化。业务功能可能因为产品进度等其它客观因素导致其部分需求或功能在本次迭代中没有提出，但可以预见的是这些功能在很大程度上会在后面的迭代中补充，这些功能可能会对当前业务有影响，将这些情况考虑进去在一定程度上会使得服务设计更加合理。在服务拆分、功能分配的时候可能会遇到这些情况，但需要避免过度设计。
最后，也需要根据自己团队的特点来设计微服务，例如组织架构会影响软件架构、以及当团队技术能力无法保障多服务协作的正确性，可以减少服务的拆分，将一些功能合并在一个服务内。
如有不正确的地方，欢迎指正交流。