微服务设计学习笔记01

第一章 微服务

什么是微服务？微服务就是一些协同工作的小而自治的服务。

主要的好处？

技术异构性，比如对于社交网络来说，图数据库能够更好地处理用户之间的交互操作，但是对于用户发布的帖子而言，文档数据库可能是一个更好的选择。
弹性，对于单块服务的系统而言，可以通过将同样的实例运行在不用的机器上来降低功能完全不可用的概率，然而微服务系统本身就能够很好地处理服务不可用和功能降级问题。
扩展，庞大的单块服务只能作为一个整体进行扩展，即时系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的，性能稍差的硬件上。

简化部署，在有几百万行代码的单块服务中，即时只有该了一行代码，也需要重新部署真个应用程序才能够发布变更。这种部署影响大，风险高，不敢轻易部署。于是在实际操作汇总，部署的频率就会变得很低，这意味着在两次发布之间我们对软件做了很多功能的修改，把大量变更一次性发布到生产环境中，这有带来一个问题，两次之间发布的差异越大，出错的可能性就越高。在微服务架构中，各个服务的部署是独立的，这样就可以更快地对特定部分的代码进行部署，如果真出了问题也会只影响一个服务，并且容易快速回滚，这也意味着客户可以更快地使用我们开发的新功能。

与组织结构匹配，微服务架构可以很好地将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。
**可组合性，**在微服务架构中，根据不同的目的，人们可以通过不同的方式使用同一个功能，在考虑用户使用该软件时这一点尤为重要。系统会开放很多接口供外部使用，当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用，如果想得到更有用的细化信息，你需要使用榔头撬开它！

对可替代性的优化，有些庞大丑陋的遗留系统，无人敢碰，却对公司的业务运营至关重要，为什么这些系统直到现在还没被取代，其实答案你很清除：工作量大，而且风险很高。当使用多个小规模服务时，重新实现某个服务或者直接删除该服务都是相对可操作的。

面向服务的架构

SOA(Service-Oriented Architecture),是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中，服务之间通过网络调用。

其他分解技术

共享库，基本上所有的语言都支持将真个代码库分解成多个库，这是一种非常标准的分解技术，这些库可以由第三方或自己的组织提供。不同的团队可以通过库的形式共享功能，比如我们可能会创建一系列游泳的集合操作工具，或者一个可以重用的统计库。但共享库也存在一些缺点，首先你无法选择异构的技术，其次你会失去独立地对系统某一部分进行扩展的能力，再次，除非你使用的是动态链接库，否则每次当库有更新的时候，都需要重新部署整个进程，以至于无法独立部署变更。
模块，有些语言提供了自己的模块分解技术，他们运行对模块进行生命周期管理，这样就可以吧模块部署到运行的进程中，并且可以不停止整个进行的前提下对某个模块进行修改。

没有银弹

微服务不是免费的午餐，更不是银弹，使用微服务需要面对分布式系统需要面对的复杂性，需要在部署、测试、监控等方面做很多工作，还需要考虑如何扩展系统，保证它们的弹性。每个公司、组织及系统都不一样。微服务是否适合，或者说需要在多大程度上采用微服务，取决于很多因素。

第二章 演化架构师

与建造建筑物相比，在软件中我们会面临大量的需求变更，使用的工具和技术也具有多样性。我们创造的东西并不是在某个时间点之后就不再变化了，甚至在发布到生产环境之后，软件还能继续演化。对于我们创造的大多数产品来说，交付到客户手里之后，还是要响应客户的变更需求，而不是简单地交给客户一个一成不变的软件包。因此架构师必须改变那种从一开始就要设计出一个完美产品的想法，相反我们应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统。架构师应该像城市规划师那样专注在大方向上，只有很有限的情况下参与到非常具体的细节实现中来。

第三章 如何建模服务

什么样的服务是好服务

松耦合，如果做到了服务之间的松耦合，那么修改一个服务就不需要修改另一个服务。一个松耦合的服务应该尽可能少地知道与之写作的那些服务的信息。这也意味着应该限制两个服务之间不同调用的数量，因为除了潜在的性能问题之外，过度的通信可能会导致紧耦合。
高内聚，把相关的行为聚集在一起，不相关的行为放在别处。

限界上下文

bounded context，任何一个给定的领域都包含多个限界上下文，每个限界上下文中的东西分成两个部分，一部分不需要与外部通信，另一部分则需要。
共享的隐藏模型，模块和服务，过早的划分

业务功能

思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下文能够提供的功能来考虑。

逐步划分上下文

一开始你会识别出一些粗粒度的限界上下文，而这些限界上下文可能又包含一些嵌套的限界上下文。

关于业务该概念的沟通

修改系统的目的是为了满足业务的需求，我们会修改面向客户的功能，如果把系统分解成为限界上下文来表示领域的话，那么对于某个功能所要做的修改，就更倾向于局限在一个单独的微服务边界之内。