7.企业应用架构模式 --- 分布策略

2.远程接口和本地接口
	进程内的调用非常快。两个独立的进程间的过程调用就慢了一个数量级。在不同机器间运行的过程又要慢一两个数量级，取决于网络拓扑。
	因此，需要远程使用的对象接口应该与就在同一个进程内本地使用的对象接口有所区别。
	本地接口最好是细粒度接口。比如，如果一个地址类，则一个好的接口将会有单独的方法，分别用于得到城市，得到州，设置城市，设置州等。
  细粒度接口非常好，因为它符合一般的面向对象原则，即尽量细分对象，使我们可以以不同方式组合和覆盖这些对象以便在将来对设计进行扩展。
  	但是，细粒度接口不能很好的用在远程调用中。当方法调用很慢时，更应该在一次调用而不是三次调用中取得或者更新城市，州和邮政编码。
  这样就产生了一个粗粒度的，不是为了灵活性和可扩展性而是为了减少调用次数而设计的接口。产生了一个一次就得到和更新详细地址信息的接口。
  虽然变成比较麻烦，但是为了性能值得这样做。
  	一旦某个对象会被远程访问到，就应该使用粗粒度的接口，应该最小化跨进程的对象协作的数量。
  	由于这些原因，就不能把在单进程环境中设计的类原封不动的搬到corba或者其他分布环境中的分布模型上。分布设计工作远不止这些。当多个
  类上的应用分布策略时，最终得到的系统会有许多的远程调用，从而需要繁琐的粗粒度接口。
  	分布对象设计的第一定律：不要分布使用对象。
  	这种情况下，怎么样有效的利用多处理器资源呢？大多数情况下使用集群系统。在每一个处理器上都部署所有的对象并在其他几个节点上复制它们。
  这样一来，每个处理器上的对象只需用到本地调用，从而运行更快。还可以使用细粒度的接口设计对象，从而得到更简单的编程模型和更好的可维护性。

3.必须使用分布的情况
	一方面要尽可能小范围使用分布对象，一方面要尽可能发挥集群的性能。
	1.一个显而易见的划分出现在业务软件的传统客户机和服务器之间。用户使用的个人计算机肯定是共享数据的不同节点。因为它们是不同的计算机，就必定
	要在不同的进程间通信。客户机与服务器的划分是典型的跨进程划分。
	2.第二种划分出现在基于服务器的应用软件(如应用服务器)和数据库之间。当然，你可以不用这样做，你可以使用类似存储过程的方法在数据库进程中运行
	所有的应用软件。但由于这样做不太实际，因此你必须有单独的进程。应用服务器和数据库可以在同一台机器上运行，但是只要你有单独的进程，就必须为远程
	调用付出大部分的性能代价。幸运的是，sql被设计成数据库的远程接口，使得你可以经常安排好食物以尽可能减少损失。
	3.另一个进程划分出现在web服务器与应用服务器之间的web系统中。最好是在同一个进程汇总运行web服务器与应用服务器，但情况可能不总是这样。
	4.还可能由于厂商不同而进行进程划分。使用的软件包可能需要在单独的进程中工作，这又会用到分布。至少一个好的软件会提供粗粒度的接口
	5.最好，还可能有一些别的原因导致你必须去划分你的应用服务器软件。也许需要想尽一切办法来避免这样。

4.关于分布边界
	在设计系统时必须尽可能限制分布边界，但在必要的时候还得考虑它们。系统中每个地方都应极力减少远程调用，这样才能使得开销最小。
	然后，还是可以在一个进程内使用细粒度对象进行设计。关键要记住只在进程内部使用它们，而在分布边界上防止粗粒度的对象，它们唯一的目的是去提供一个到细粒度
  对象的远程接口。粗粒度对象实际上不做任何事情，从而充当细粒度对象的外观。这个外观只是为分布需要而使用---因此称为远程外观。
  	使用远程外观能减少粗粒度接口引入的困难。这样，只有那些真正需要远程服务的对象才使用粗粒度接口，这也使得开发人员清楚所付出的代价。透明有它的好处，但不要
  期望一个潜在的远程调用透明。	
  	然后，让粗粒度接口仅仅作为外观，可以让使用者无论何时只要他们知道自己正运行于同一进程中就使用细粒度对象。这使得分布策略非常明显。通常和远程外观一起使用的
  还有数据传输对象。因为不知是需要粗粒度的方法，还需要传输粗粒度的对象。当请求一个地址时，需要将信息放在一个数据块中发送回去。通常不能把领域对象本身直接发送
  过去，因为它们绑定到一个由细粒度的本地对象引用组成的网络中。所以应该讲客户端需要的所有数据打包在一个特定对象中以便传输---就成了所谓的数据传输对象。双方都使用了
  数据传输对象，很重要的一点是要保证它们不能引用网络间任何非共享的事务。事实上，一个数据传输对象一般只引用其他的数据传输对象和一些如字符串等原始类型的对象。
  	进行分布的另外一种方式是使用一个代理在进程间迁移对象。这个思想用到了延迟加载方案来传递对象，不是用数据库的延迟读而是在网络之间移动对象。最困难的部分在于：要
  保证结果不会产生太多的远程调用。

5.分布接口
	由于历史原因，不论是全局过程还是对象的方法，分布组件的接口都基于远程过程调用(RPC)。然后，在过去几年，开始出现http上基于xml的接口。soap可能会是这种接口
  最常用的形式。
  	有些原因使得基于xml的http通信非常方便。通过它可以很容易的在一个往返中传递大量结构化的数据。由于远程调用需要被最小化，因此这是一件好事。xml是一种通用的格式，
  各种平台都有它的解析器，再加上http协议的广泛使用，使得建立在不同平台上的系统可以互相通信。xml是基于文本的，便于人们观察传输的内容。当由于安全和政治方面的原因
  使得我们难以打开其他端口时，http协议还是可以很容易的通过各种防火墙。
  	即便如此，类和方法的面向对象接口也很有用。将所有的传输数据转化为xml格式和字符串给远程调用增加了客观的开销。因此，使用远程调用比基于xml的接口要高效的多。如果系统
  间的二进制编码机制相同，基于xml的接口只是一堆花哨的东西。因此，如果两个系统是相同的平台构建的，最好使用系统自己的远程调用机制。web service 在不同的平台互相交互时
  能提供便利。建议只有在无法使用更直接的方式时，才使用基于xml的web service。
  	当然，也可以通过将http接口置于一个面向对象的接口之上，来同时获得这两种方式的优点。所有到web服务器的调用都被http协议传递底层的面向对象接口处理。这在一定程度上能
  获得两者的长处，但由于需要web服务器和主机提供远程面向对象的接口，从而增加了系统的复杂度。因此，应该在同时需要使用http协议和远程面向对象的api时，或者在安全和事务处理
  机制的远程面向对象api的设施能比本地对象更容易的处理这些问题时才使用这种方式。
  	web service 更适合使用异步方式。

https://juejin.im/post/5c5075ee6fb9a049a7123959