什么是微服务，微服务好处，微服务原则

什么是微服务

微服务就是一些协同工作的小而自制的服务。

1.        很小，专注于做好一件事

随着新功能的增加，代码库会越来越大。时间久了代码库会非常庞大，以至于想要知道该在什么地方修改都很困难。尽管我们想在巨大的代码库中做到清晰地模块化，但事实上这些模块之间的界限很难维护。相似的功能代码开始在代码库中随处可见，使得修复bug或实现更加困难。

在一个单块系统内，通常会创建一些抽象层或者模块来保证代码的内聚性，从而避免上述问题。内聚性是指将相关代码放在一起，在考虑使用微服务的时候，内聚性这一慨念很重要。Robert C.Martin 有一个对单一职责原则（Single ResponsibilityPrinciple,http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle）的论述：“把因相同原因而变化的东西据聚合到一起，而把因不同原因而变化的东西分离开来。” 该论述很好地强调了内聚性这一慨念。

微服务将这个理念应用在独立的服务上。根据业务的边界在确定服务的边界，这样就很容易确定某个功能代码应该放在哪里。而且由于该服务专注于某个边界内，因此可以很好的避免由于代码库过大衍生出的相关问题。

代码库多小才算小的，一个微服务应该可以在二周内完成重写。

 

2.        自治性

一个微服务就是一个独立的实体。他可以独立的部署在PAAS上，可以用昨晚一个操作系统进程存在，我们尽量避免把多个服务部署到同一台机器上。

服务之间通过网络调用进行通信，从而加强了服务之间的隔离线，避免了紧耦合。

  如果系统没有很好的解耦，那么一旦出现问题，所有的功能都将不可用。有一个黄金法则是：你是否能够修改一个服务并对其进行部署，而不影响其它任何服务？

 

微服务的好处

1.        技术异构性

在一个由多个服务相互协作的系统中，可以在不同的服务中使用最适合该服务的技术。如果系统中的一部分需要做性能体升，可以使用性能更好的技术栈来重构该部分。系统中的不同部分也可以使用不同的数据存储技术。

2.        弹性

弹性工程学的一个关键概念是舱壁。如果系统中的一个组件不可用了，但并没有导致级联故障，那么系统的其它部分还可以正常运行。服务边界就是一个很明显的舱壁。单单块系统中，如果服务不可用，那么所有的功能都会不可用。对于单块服务的系统而言，可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率，然而微服务系统本身就能够很好的处理服务不可用和功能降级问题。

3.        扩展性

针对具体的服务进行扩展

4.        简化部署

  在微服务架构中，各个服务的部署是独立的，这样就可以更快的对特定部分的代码进行部署。如果真的出了问题，也只会影响一个服务，并且容易快速回滚。

 

5.        与组织结构相匹配

  我们经历过太多由于团队和代码库过大引起问题的情况。当团队是分布式的时候，问题会更明显。我们也知道在小型代码库上工作的小团队更加高效。

  微服务架构可以很好的将架构与组织结构相匹配，避免出现代码库过大，从而获得理想的团队大小及生产力，服务的所有权也可以在团队之间迁移。

6.        可组合性

分布式系统和面向服务架构声称的主要好处是易于重用已有功能。而在微服务架构中，根据不同的目的，人么可以通过不同的方式使用同一个功能。

在微服务架构中，系统会开放很多接口共外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。

 

7.        对可替代性的优化

  使用微服务架构的团队可以在需要时轻易的重写服务，或者删除不在使用的服务。

 

 

微服务的原则

1.        围绕业务概念建模

经验表明，围绕业务的界限上下文定义的接口，比围绕技术概念定义的接口更稳定。针对系统如何在这个领域进行建模，不仅可以帮助我们形成更加稳定的接口，也能确保我们能够更好的反应业务流程的变化。使用界限上下文来定义可能的领域边界。

 

2.        接受自动化文化

3.        隐藏内部实现细节

4.        让一切去中心化

5.        可独立部署

6.        隔离失败

7.        高度可观察