《微服务设计》读书笔记（关于微服务的一点想法）

一、在学习软件构造、设计相关知识时，你们应该有学习到内聚性的概念：即把因相同缘由而变化的东西聚合到一块儿，而把因不一样缘由而变化的东西分离开来。而数据库

微服务将这个理念应用在独立的服务上。根据业务的边界来肯定服务的边界，这样就很容 易肯定某个功能代码应该放在哪里。

我我的以为，微服务就是将原来的单体应用安装功能进行切分，而后各个服务之间经过通讯(跨进程、跨机器)来共同完成原来的单体应用所提供的功能。
微服务对比与原来的单体应用，有它的优点，如服务的自治性加强、但同时也会带来一些其余问题，如性能、复杂度等问题。架构

二、想要使用微服务，首先是要清楚哪些业务或者功能应该成为单独的服务。《微服务设计》一书中给了一些建议：分布式

当你在思考组织内的限界上下文时，不该该从共享数据的角度来考虑，而应该从这些上下 文可以提供的功能来考虑。
这个上下文是作什么用的。
组织结构和软件架构会互相影响。

固然，书中列出的建议不止这些，我也想谈一谈我本身的一些想法。微服务

• 我以为首先要从业务出发(单独的基础服务，例如分布式事务、数据库同步服务例外)，这一块业务咱们须要实现怎样的功能，它在系统中处于什么样的位置，它须要与哪些服务进行交互(提供接口和消费接口)。知道了业务功能在整个系统的位置，有助于咱们进行决策。
• 其次，考虑业务极有可能的变化。业务功能可能由于产品进度等其它客观因素致使其部分需求或功能在本次迭代中没有提出，但能够预见的是这些功能在很大程度上会在后面的迭代中补充，这些功能可能会对当前业务有影响，将这些状况考虑进去在必定程度上会使得服务设计更加合理。在服务拆分、功能分配的时候可能会遇到这些状况，但须要避免过分设计。
• 最后，也须要根据本身团队的特色来设计微服务，例如组织架构会影响软件架构、以及当团队技术能力没法保障多服务协做的正确性，能够减小服务的拆分，将一些功能合并在一个服务内。

若有不正确的地方，欢迎指正交流。性能