1.微服务设计 --- 微服务

    微服务主要围绕业务领域建模，避免了传统的分层架构引发的很多问题。

	<<领域驱动设计>> 用代码呈现真实世界的重要性。持续交付理论告诉我们如何有效及更高效的发布软件产品，并指出保持每次提交均可发布的重要性。
  六边形架构理论把我们从分层架构中拯救出来，从而能够更好的实现业务逻辑。借助虚拟化平台，我们能够按需创建机器并调整大小。类似 Amazon 和 
  Google 这样的大型组织，有很多小团队，他们对各自某个服务的全生命周期负责。Netflix 构建大型反脆弱系统。
  	领取驱动设计，持续交付，按需虚拟化，基础设施自动化，小型自治团队，大型机器系统。

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

	1.1.1 很小，专注于做好一件事
	内聚性是指将相关代码放在一起，把因相同原因而变化的东西聚合到一起，把因不同原因而变化的东西而分离。
	微服务将这个理念应用在独立的服务上。根据业务的边界来确定服务的边界，这样就很容易确定某个功能代码应该放在哪里。

	代码库多小才算小？
		一个微服务应该可以在2周内完全重写。
		足够小即可，不要太小。

	使用的服务越小，独立性带来的好处就越多。但是管理大量服务也会越复杂。

	1.1.2 自治性
		一个微服务就是一个独立的实体。可以独立的部署在paas,也可以作为一个操作系统的进程存在。我们应该尽量避免把多个服务部署
	  到同一台机器上。尽管这种隔离性会引发一些代价，但它能够大大简化分布式系统的构建。

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

	  	这些服务应该可以彼此独立进行修改，并且某一个服务的部署不应该引起该服务消费方的变动。对于一个服务来说，我们需要考虑的是
	  什么应该暴露，什么应该隐藏。如果暴露的太多，那么服务消费方与该服务的内部实现产生耦合。这会使得服务和消费方之间产生额外的
	  协调工作，从而降低服务的自治性。
	    服务会暴露 API，然后服务之间通过这些 API 进行通信。API 的实现技术应该避免和消费方耦合，这就意味着选择与具体技术不相关
	  的API实现方式，以保障技术的选择不被限制。
	    如果系统没有很好的解耦，那么一旦出现问题，所有的功能将不可用。你是否能够修改一个服务并对其进行部署，而不影响其他服务？

2.主要好处
	微服务有很多不同的好处，其中很多好处也适用于任何一个分布式系统。

	1.2.1 技术异构性
		在一个由多个服务互相协作的系统中，可以在不同的服务中使用最合适该服务的技术。尝试使用一种合适所有场景的标准化
	  技术，会使得所有的场景都无法得到很好的支持。

	1.2.2 弹性
		弹性工程学的一个关键概念是舱壁。服务边界就是一个很显然的舱壁。在单块系统中，如果服务不可用了，那么所有的功能都不会不可用。
	  对于单块服务的系统来说，可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率，然后微服务系统本身就能够很好的处理
	  服务不可用和功能降级问题。

	1.2.3 扩展
		庞大的单块服务只能作为一个整体进行扩展。如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展。

	1.2.4 简化部署
		在有几百万代码行的单块应用中，即使只修改了一行代码，也需要重新部署整个应用程序才能发布该变更。这种部署的影响很大，风险很高，
	  于是在实际操作中，部署的频率就会下降。这意味着在两次发布之间我们对软件做了很多功能增强，但直到最后一刻才把这些大量的变更一次性的
	  发布到生产环境中。这时另外一个问题就出现了：两次发布之间的差异越大，出错的可能性就越大。
	    在微服务架构中，各个服务的部署是独立的，这样就可以更快速的对特定的步伐的代码进行部署。如果真的出了问题，也影响一个服务，并且容易
	  快速回滚。

	1.2.5 与组织架构匹配
		微服务架构能够很好的将架构与组织架构相匹配，避免出现过大的代码库,从而获得理想的团队大小以及生产力。

	1.2.6 可组合性
		在微服务架构中，系统会开放很多接缝供外部使用。当情况发生改变的是，可以使用不同的方式构建应用。而整体化应用只能提供一个粗粒度的接缝
	  供外部使用。

	1.2.7 对可替代性的优化
		当使用多个小规模服务时，重新实现一个服务或者是直接删除代码该服务都是相对可操作的。使用微服务架构的团队可以在需要的时候轻易的重写服务，
	  或者删除不需要的服务。

3.面向服务的架构
	SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中，
  服务之间通过网络调用，而非采用进程内调用的方式进行通信。
    它的目标是在不影响其他任何人的情况下透明的替换一个服务，只要替换后的服务的外部接口没有太大变化即可。
    实施 SOA 时会遇到很多问题: 通信协议(例如 SOAP)如何选择，第三方中间件如何选择，服务的粒度如何确定等。	


4.其他分解技术
	微服务架构的主要优势：首先它具有较小的粒度，其次它能够在解决问题的方法上给你更多的选择。

	1.4.1 共享库
		基本上所有的语言都支持将整个代码库分解成多个库，这是一种非常标准的分解技术。这些库可以由第三方或者自己的组织提供。
		不同团队和服务可以通过库的形式共享功能。
		团队可以围绕库来组织，而库本身可以被重用。
		缺点：
			首先，你无法选择异构的技术。一般来说，这些库只能在同一个语言中，或者至少在同一个平台上使用。
			其次，你会失去独立的对系统某一部分进行扩展的能力。
			再次，除非你使用的是动态链接库，否则每次当库更新的时候，都需要重新部署整个进程，以至于无法独立的部署变更。
			最糟糕的影响是，你会缺乏一个比较明显的接缝来建立架构的安全性保护措施，从而无法确保系统的弹性。
		共享库确实有其相应的应用场景。有时候你会编写代码来执行一些公共任务，这些代码不属于任何一个业务领域，并且可以在整个组织
	  中进行重用，很显然这些代码就应该成为可重用的库。但是你还需要很小心，如果使用共享代码来做服务之间的通信的话，那么它会成为一个
	  耦合点。 

	1.4.2 模块
		除了简单的库之外，有些语言提供了自己的模块分解技术。它们允许对模块进行生命周期管理，这样就可以把模块部署到运行的进程中，并且
	  可以在不停止整个进程的前提下对某些模块进行修改。
	    OSGI(开放服务网关协议)
	    erlang 采用了不同的方式，模块的概念内嵌在 erlang 语言的运行时中，因此这种模块化分解的方式是成熟的。你可以对erlang的模块进行
	  停止，重启或者升级等操作，且不会引起任何问题。erlang 甚至支持同时运行一个模块的多个版本，从而可以支持更加优雅的模块升级。但还是会
	  存在于共享库类似的缺点，即它会大大限制我们采用新技术和独立对服务进行扩展的能力，并且有可能会导致过度耦合的集成技术。
	    尽管在一个单块进程中创建隔离性很好的模块是可能的，但很少真正有人能做到。而进程边界的存在则很可能有效的避免这种问题，尽管这不是使用
	  进程隔离的主要原因，但事实上确实很少人能够在同一个进程内部做到很好的模块隔离。

5.没有银弹

 

1.什么是微服务

 

3.面向服务的架构
 

 

4.其他分解技术

 

5.没有银弹