基于Spring-DM实现分布式服务框架(DSF)
基于Spring-DM实现分布式服务框架(DSF)(一) 发布时间:2008年01月29日作者:BlueDavy
阅读次数:448次类别:OSGi、SCA永久链接Trackback
经过上篇分析分布式服务框架的blog后，正式对之前的基于OSGi实现分布式服务框架的系列改名(顺便把分布式服务框架改为使用DSF缩写)，因为已经决定基于Spring-DM来实现，为什么呢，而且为什么一定要是Spring-DM，而不直接说Spring呢？
今天是Spring-DM 1.0 release的大好日子，，不容易呀，做了这么久，具体怎么样还没来得及细看，不过之前有用过1.0 m2，已经觉得很不错了，相信1.0 release更不
会失望。
在我眼里看来，Spring是个很大的东西，其实DSF需要的基础的东西并不多，但又希望保持微核性和扩展性，插件化、具备良好扩展支持的框架无疑是最佳的选择，OSGi无疑是个好的选择，但基于OSGi要自己去实现的东西实在是太多了，Spring-DM则是能满足
我以上两点需求的最佳选择，既有了插件化的框架，又有了很多可用而且是很强大的东西，尤其是Spring在本地调用和远程调用的透明化提供了优秀的设计支持和指导，例如Spring提供的 HessianServiceExporter、JNDIObjectFactoryBean等等，而且Spring
和OSGi结合后，就可以根据需求来选择自己所需的Spring的那些增强功能了，不用每
次都抱着整个巨大的Spring，当然，目前Spring还没完全剥离好，等Spring-DM 1.1后会好很多。
在之前的分析分布式服务框架的blog中，已经说到其实实现DSF简明扼要的说就是：高效的存储、查找策略+高效的通讯策略+满足需求的服务模型+强大的集成能力，其实这里
面最重要的呢，又是强大的集成能力，为什么呢，因为呢，前两个关键点都是有挺多的可选方案的，需要根据系统运行的情况来做出不同的选择，这个时候就要求DSF具备很好的集成能力，使得可以很方便的进行不同实现方案的切换，这点Spring已经向世人证明了很多次了，鉴于这些原因Spring-DM荣幸的入选成为DSF的选择。
来看看基于之前的那篇分析分布式服务框架的blog以及选择了Spring-DM后，DSF变成什么样了：
是不是觉得和之前的DSF的图有很多的不同的地方，至于为什么会变成这样，可以去看看分析分布式服务框架的blog，不在此细说，在此会详细的介绍下目前DSF第一个版本V 0.7，也就是上图中的每个部分：
先全局的说下，仍然是分为服务应用端和服务中心，但是从图中可以看出，服务查找和调用的机制和以前的有所不同，在DSF中服务仅把其元信息直接在服务中心进行注
册，此元信息会由服务中心写入分布式的缓存DB：MemcacheDB中，当服务应用端进行服务调用时，它将直接访问MemcacheDB来查找到目标服务的访问机制，然后直接和目标服务应用端进行通讯，而不经过服务中心路由，这里要稍微说下为什么采用MemcacheDB，其实就是解决DSF中所说的高效的存储、查找机制，当然，里面其实还有个细节，就是cluster的考虑，可以想想，如果目标服务的元信息是直接缓存在服务应用端的话，那么当目标服务元信息发生改变时，那通知起来是件非常麻烦的事，所以干脆找个支持cluster持久和高效缓存的东西，还好有了MemcacheDB，当然，其实你也可以根据你所面对的应用的实际需求来定，例如，你的目标服务压根就不可能存在元信息变化的现象，那完全可以直接把目标服务的元信息缓存到服务应用端 (甚至这步可以在部署期直接完成)，这些等DSF做到后期版本后，可以考虑机制调整的支持，但在V 0.7中将会采用图示的方案。
经过机制的改变后，服务中心就变得非常简单了，而且压力是非常的小，它将来更多的需要承担服务的管理和监控的职责，逐步的会压力增大，这里就不去过多的讲它了，还是来看看服务应用端，其实也就是V 0.7需要干的活了：
1、服务查找
这个服务查找就是负责和MemcacheDB通讯的了，根据服务模型进行服务的过滤查找，只是要考虑以后切换为其他查找方式(如基于分布式文件系统、服务查找后本地缓存等)的支持，由于是基于Spring-DM的，不会有什么问题。
2、发布服务
参考Spring的ServiceExporter来实现，在V 0.7中，暂时只提供jndi的方式，jndi server采用jboss jnp，而以Hessian、Webservice的方式发布，都是Spring直接
就支持的，:)，只是当服务应用端不是采用Spring实现时，需要做个集成策略的实现。
3、调用服务
参考Spring的ObjectFactoryBean实现，由于V 0.7只有JNDI、Hessian方式，Spring已经分别提供了JNDIObjectFactoryBean和 HessianProxyFactoryBean，所以这块暂时不用去考虑了。
在后续版本中这块需要在缓存等方面多加考虑。
4、和服务应用端的集成
在V 0.7中暂时假设服务应用端也是基于Spring的，所以就暂时不考虑集成的问题了。
OK，到此为止，剩下的两个工作就是：
1、服务元信息模型
服务元信息模型完全参考OSGi Service。
在V 0.7中将只支持xml方式描述服务元信息模型的注册，这里需要完成的就是将xml解析为元信息模型。
2、服务管理端
V 0.7仅提供服务列表的查看、服务注册、元信息修改以及卸载。
V 0.7需要做的就是把DSF的架子搭好，保证好基于DSF的Scable的可行性，当然，其实service本身也是要考虑Scable的(如 service操作的资源等)才行，在后续0.7-->1.0的过程中将会从细节加以改进，如支持更多的通讯协议、支持更多种服务应用端的集成、提高性能等。
Let"s move toward V 0.7！
Spring进军SOA领域
发布时间:2008年01月25日作者:BlueDavy
阅读次数:526次类别:OSGi、SCA永久链接Trackback
昨天刚分析完分布式服务框架，今天便看到Spring Integration 1.0 M1发布的消息，这也为Spring进军SOA领域拉开了序幕。
Spring 的动作一直就颇多，其实它自己就是个非官方的标准，不过它显然更聪明，因为它基于一个强大的pojo container结合pojo enhanced机制使得它可以很容易的集成在其他领域极为专业的东西，而不是自己去竞争，更加好的是它提供的是选择，这也就使得Spring很容易的成为了最为流行的框架，而Spring和OSGi的结合更是进一步的提升了它的应用面，因为估计有很多人忌讳spring的巨大而不使用它了，至少我以前就这么选择过，选用OSGi这样的模块化框架固然是缺少了很多企业应用需求的东西的支持，但对于有些应用来讲完全可以自己去实现，但对于大而复杂的应用来说直接选用OSGi几乎是不可能的，因为要自己去实现太多的东西，还好Spring和OSGi结合在一起了。
说了这么多和标题无关的话，只是想表明 Spring其实已经具备了分布式服务框架中很重要的一些因素：可插拔(这样的话完全可以根据应用的需求来搭建微小还是巨大的东西)、强大的集成能力，而且Spring本身之前就已经提供了一些分布式交互的支持，如JNDIObjectFactoryBean、 HessianServiceExporter等等，回到正题，由于Spring本身就具备了这些特征，因此其实以它来实现分布式服务框架确实是个很好的选择，Spring 自己果然也没浪费这样的机会，顺理成章的推出了Spring Integration。
Spring Integration是基于Message机制来达到Bean交互的，这个在上篇分析分布式服务框架的blog里已经有所提及，在服务的交互上是有多种协议可去选择的，Spring Integration选择了JMS机制，从它目前公布的例子也能看出，使用起来有点的晦涩，但是功能方面确实还不错，已经具备了分布式服务框架的整个的架子：
1、服务模型
在Spring Integration里准确的说应该是一个供bean使用的Message Queue或Channel就是服务了。
2、服务的注册中心
由于在Spring Integration里交互其实是通过message来完成的，因此服务的注册中心中其实只需要能提供message的地址和queue名或Topic名就可以了，这个在现在的IBMMQ Broker这样的东西是直接支持的。
不过在目前的Spring Integration还没看到这块。
3、发布服务的方式
源于上面服务的注册中心，其实就是发布mq server地址和queue名了。
4、查找服务和调用服务的方式
目前由于无服务中心，没有查找这回事。
调用服务目前是通过直接往目的地发消息来实现，当然Spring Integration已经屏蔽了调用JMS的细节。
5、服务的组装
组装这块目前Spring Integration也没有清晰的提供。
6、稳定性和性能
由于是基于message机制的，稳定性和性能主要就取决于MQ了。
根据这个可以看出，目前虽然是有架子了，但还是有一定的距离，不过毕竟是1.0 M1，希望等1.0 release的时候能让大家眼前一亮吧。
由于和自己想象中的分布式服务框架还是有很多的不同，因此还是继续去实现自己的分布式服务框架。
分析分布式服务框架
发布时间:2008年01月24日作者:BlueDavy
阅读次数:526次类别:OSGi、SCA永久链接Trackback
技术是为需求而服务的，分布式服务框架也同样如此，它不是凭空诞生的，也是因为有这样的需求才会有分布式服务框架这么样的东西诞生，在这篇blog中来详细的分析分布式服务框架诞生的原因(其实也是需要用分布式服务框架的应用场景，这里隐含的意思就是并不是什么应用都需要分布式服务框架的)、分布式服务框架需要提供的feature 以及实现这些feature可选的技术方案。
其实这篇blog应该写在实现分布式服务框架系列blog之前，:)，不废话了，来看为什么会需要分布式服务框架，在一个不断发展的大型应用中，系统的业务和功能不断的增加，同时技术在不断的发展、团队在不断的变化，很容易造成的现象就是：各个子系统、模块实现的技术五花八门，部署时各子系统的方式和要求不同，各个子系统之间的交互方式和方法不统一。这种现象带来的问题就是整个系统感觉很混乱，不过技术毕竟是不断的
发展，因此各子系统、模块的具体实现技术要完全限制应该是不太可能的，也没必要，但会希望系统对外提供的功能能采用统一的部署以及交互方法，这样的话每个子系统能保持其黑盒的实现方式，其他子系统不想也不需要关心它的实现方式，只需要能够统一的方式调用到它们提供的功能就可以了，这是出现的第一个需求。
起初整个应用部署在一台机器上，但随着系统的功能越来越多，不得不不断的增加机器以减轻服务器的压力，但很快就出现瓶颈，不得不把应用分层部署，这样可以撑一段时间，在撑过一段时间后发现再度出现瓶颈，于是希望能够再度的把系统进行划分，这个时候就变成了希望能够以非常细的粒度来部署了，而不是把一堆的功能都部署在同一台机器上，这样带来的好处是系统的重用性能够再度的增强，服务器的压力能够有效的降低，使得系统可以以较低的成本继续保持Scable（就像google），其实这也是ebay的演变过程，大家可以去看看那个著名的ebay架构演变的PPT，还有一篇中文的ebay是怎样炼成的。从上面的需求场景描述中可以看出，需要分布式服务框架的场景并不是很多，这里还有一种场景没去提及，那就是对于一个大型企业而言，由于需要用到的软件多种多样，其实也是有分布式服务框架的需求的，但还是有些不同，因为要去满足那种场景的方法可以更为简单。
分析下分布式服务框架的应用场景，可以得知，分布式服务框架的诞生目的主要有两个：
1、约束需要对外提供的功能，保证其以一个统一的方式来对外提供和获取；
2、分布式的部署细粒度的功能。
在确定了这两个目的后，来详细的分析下为了达到这两个目的，需要提供些什么feature。要约束对外提供的功能，保证以统一的方式来对外提供和获取，首先需要制定的标准是功能到底以什么方式来对外提供，这里首先诞生了服务这个很好很形象的名词，对外提
供的功能其实也就是为别人提供的服务了，那么服务里到底有些什么呢，面向接口自然是首选，所以服务都以接口方式来提供，另外可能就是会有一些服务的元信息了，如服务的名称、描述、依赖、所在机器等等；接着要完成的就是如何把各子系统对外提供的功能定义成服务呢，这里要求分布式服务框架能提供强大的集成能力，例如子系统是采用spring来实现，那么就需要支持能把spring的bean直接定义成服务；定义服务完成了，这个时候要解决的问题就是其他的子系统怎么知道有这些服务的存在呢，因此需要提供一个统一的服务的注册中心，同时相应的带来的问题就是各个服务应用端怎么来查找这些服务，怎么调用这些服务，这也是分布式服务框架需要解决的，在提供了上面的这些feature后，第一个需求就可以基本实现了。
分布式的部署细粒度的功能，这个在第一个需求达成的情况下，直接就可以实现了，因为分布式服务框架对服务应用端的粒度并没有要求，可粗可细，只是分布式的部署细粒度的功能其实潜在的带来了另外的需求，那就是怎么样把这些细粒度的服务直接组装来满足业务的需求，这也是分布式服务框架应该提供的功能；同时，还要注意的一点是，当变成细粒度的分布式部署的场景时，系统的稳定性和性能是会受到影响的，对于大型应用来讲这两点偏偏又是非常重要的，分布式服务框架需要对此进行考虑。
.......................................................咖啡一杯，休息一下.......................................................
继续，上面分析完毕后产生了分布式服务框架的基本Feature，来总结看看，并同时对其进行可选的实现技术的分析：
1、服务模型
在服务模型中需要详细定义服务模型包含了哪些信息，而这些信息也就决定了服务在发布时需要提供的信息，同时也是为服务查找和调用提供的信息。
2、服务的注册中心
服务的注册中心在分布式服务框架中充当的就是服务信息的存储场所的作用，同时它还需要提供的一个重要的功能就是查找服务，这两个最重要功能最重要的就是稳定、高效以及支持Cluster。
存储服务信息上可采用数据库存储、分布式文件系统存储等，查找服务需要的就是支持高效的查找，这个要根据服务的查找方法等来建立相应的缓存和索引，这里需要注意的是在cluster情况下的处理，选用数据库存储或分布式文件系统存储自然是不会有cluster的问题的。
另外一个需要确定的就是服务应用端怎么调用服务注册中心提供的管理接口，可采用的技术有JNDI、JMS、WebService等等N多种实现方式，可以根据具体的性能要求、实现方法、需求等来进行选择。
从扩展方面去看，服务的注册中心应该提供多种服务应用端和注册中心的交互协议的选择、扩展。
3、发布服务的方式，支持Spring、EJB3等等
支持直接的把服务应用端的功能发布为服务，发布的方式更多的是xml、annotation等方式，就是一种很不错的设计，所以要根据服务应用端采用的技术而定，常见的如spring、EJB，这个完全根据分布式服务框架所面对的应用场景而定，如果你的服务应用端都是基于Spring的，那么就可以暂时只提供Spring的方式了。
注册服务方面的技术基本也不用选择，因为它其实是根据服务应用端采用的技术而决定的，相当于提供一个集成的接口而已，由此接口去完成和服务中心的交互。
但这里有个关键的实现技术需要选择，就是把服务以什么方式对外提供，例如有JNDI、Webservice、JMS等等，就像Spring中的 HessianServiceExporter，这里需要的是服务框架本身支持好这些协议，至于到底要实现多少种也是根据需求来看了，而各种协议的实现可以选用协议对应的成熟产品，如jndi有jboss jnp，也可以自己根据需求实现。
也许在spring中我们可以这么来发布service：
4、查找服务和调用服务的方式，支持Spring、EJB3等等
查找服务和调用服务方面，需要做到的就是能够让服务应用端透明的使用远程的服务，所以其实也是和服务应用端采用的技术相关的。
当然，它本身需要提供以各种协议和服务中心通讯，以各种协议调用远端服务的支持，另外就是同步、异步的支持等，还需要从高效性去考虑。
对于使用者来说则比较简单，也许在Spring中我们可以这么来调用远端的service：
5、服务的组装
服务的组装需要提供的就是将服务中心的服务进行组装，以实现复杂的业务需求，这里面需要包括容错等等的支持，同样，高效性也是这里面的重点。
可选用的技术有采用事件框架、jbpm等。
6、稳定性和性能
通常来讲，需要用到分布式服务框架的应用在稳定性和性能方面都会有很高的要
求，当然，稳定性更多的是通过避免Single Point的方式来提供，但同时软件层面也应该尽量避免无谓的错误，从技术角度上来讲可以采取fail-fast的思想来实现。
性能方面，需要根据使用时的压力情况来决定，如查找服务时太慢，需要考虑提升服务中心查找服务的效率，增加索引，使用分布式存储等等都是可采用的方式，提升性能的方面其实可采用的方案是非常多的，但每种技术几乎都是需要非常专业的人才去实现的。
上面分析的feature只是分布式服务框架的基本feature了，一个强大的分布式服务框架的话实现的东西会比这个多很多(例如提供服务管理端、监控端、IDE等)，不过主要会是细节上，在具备了这些基础feature的情况下，细节就决定了高低了，:)。
分布式服务框架的引入也许会降低些性能，但应用的适当的话，则能充分发挥服务器性能，并且很大程度的降低系统Scable的成本，至于开发效率的话我不觉得是分布式服务框架需要解决的问题。
服务框架其实对于所有应用而言几乎都是需要的，而且非分布式的服务框架可选的是有很多的，但分布式服务框架可选的目前基本是没有，所以如果不是应用真的需要，没有必要去实现分布式服务框架（就像在企业应用模式里Martin Fowler讲的一样，尽量不要分布式，:)），因为分布式服务框架对于技术层面还是有挺高的要求的，说简单点呢，就是高效的存储、查找策略+高效的通讯策略+满足需求的服务模型+强大的集成能力构成了分布式服务框架的核心技术实现。
ps：在写完这篇blog后，发现自己在基于OSGi实现分布式服务框架（四）里面写OSGi
不适合其实是个不准确的词，因为在服务的应用端其实是可以采用OSGi的，不过以分布式服务框架而言，OSGi是没有什么适用的场景，除了服务模型可参考外，但在服务应用端而言，OSGi仍然是个很好的选择。
基于OSGi实现分布式服务框架历程(四) 发布时间:2008年01月23日作者:BlueDavy
阅读次数:179次类别:OSGi、SCA永久链接Trackback
在这个篇幅中将来分析下这个分布式服务框架的服务的生命周期的管理的问题，在分布式服务框架中，支持服务的动态部署、卸载、升级是很关键的，至于服务的生命周期是否需要做到像 OSGi那样的动态通知，在这个篇幅中会进行分析，并最终形成这个分布式服务框架的生命周期模型以及到目前为止的服务架构模型。
先来分析下服务的生命周期是否需要做到像OSGi DS的动态通知，这里以服务组件安装为例稍微的说下OSGi DS服务的生命周期模型，在OSGi DS中，当有新的Service Component 安装时，首先会检查其是否lazy，如是lazy或此Service Component对外提供服务则完成安装，生成ServiceRegistration对象放入其服务中心；如不是lazy或此Service Component不对外提供服务，则首先检查其引用的服务是否可用，如不可用则尝试激活引用的服务，如所有引用的服务均可用，那么激活此 Component，对外提供此Service，并发布Service Active的事件；服务生命周期事件管理器在接收到Service Active的事件后，将会查找所有引用此Service的Component，如Component未激活，则尝试激活，如
已激活，则根据配置的 bind-method注入此Active的Service Instance。
根据上面的分析，到分布式的服务应用的环境下，来看看，下图为一个典型的分布式服务应用的图示：
根据OSGi DS服务的生命周期模型，那么当我们在服务应用端部署了一个分布式服务时，此服务首先需要到服务中心进行注册，在注册时，需检查去所引用的服务是否可用，如可用，得激活此服务，同时需要将此消息发送给所有引用了此服务的服务应用端，这整个过程说起来是相当的顺畅的，但我们可以想想，如果这个服务是个基础服务，被N多服务应用端引用了，那这个时候会是个什么状况，那要通知到多少的服务器呢(可以想象100+的服务群)，尽管可以cluster+同步，:)，更复杂的情况，当此服务引用了其他N 个服务，首先需要发消息尝试激活这些服务，然后那些服务激活后又带来了N个服务的激活，这个就把整个过程变得极度繁琐了，整个的实现难度和逻辑复杂度大大提升了，动态的处理生命周期的变化将会带来很大的技术难度以及不可控因素，例如在高并发的场景
时某服务突然不可用了，但它的通知的消息还在传递，那结果会怎么样呢？既然这么难控制，那就干脆不去控制这种动态的变化了，简化整个生命周期模型，保证实现的简便性和系统的高稳定性，这也是实现所有系统必须遵循的原则：“简单(但不是简陋)到可控、满足需求为止”。
鉴于以上的分析，在这个分布式服务框架中将采取一种适合大型分布式应用使用的服务生命周期模型：
1、服务安装时
当服务在应用端被安装时，首先注册其Service元信息到本地服务中心，接着判断如服务需要注册到远程服务中心，则进行注册，注册完毕后，根据服务引用的服务的信息生成相应的服务Proxy对象，注入到此服务中，同时激活服务。
2、服务卸载时
当服务在应用端被卸载时，首先从本地服务中心中删除相应的Service元信息，如此服务注册到了远程服务中心，那么同时删除远程服务中心的Service元信息。
3、服务升级
服务升级需要做的其实就是替换Service元信息，同时刷新classloader中的服务实例。
通过这个容易实现的服务生命周期模型可以看出，实现出来的这个分布式服务框架将会很好的支持服务的动态部署、卸载和升级，但并没有支持到服务的状态的通知等，其实也不是很必要，不过在目前的这种情况下需要解决的是调用的高效的问题，因为在不知道引用的服务的状态的情况下，最复杂的就是每次都得发起调用，这里需要有一个高效的缓存机制，以避免无谓的调用(如服务压根就不可用呀，或者服务没改变，参数也没改变
的情况)，:)，这个具体怎么实现大家可以先想想，在后续的章节中会详细的介绍。
经历到目前这步后，大家会发现，OSGi在整个的分布式服务框架中开始逐步消失，确实，OSGi在分布式领域的不足 (最强的DS在分布式领域非常不适合)已经让它不是很适合作为实现这种大型分布式场景应用的框架了，但这并不意味着OSGi就没什么用了，OSGi在很多应用领域仍然是王者型的框架，只有最适合的，没有最好的，:)，而且OSGi的很多思想(例如服务的模型，所以其中还是有很多DS的影子)其实也在指导着这个分布式服务框架的思想，所以即使最后这个实现的分布式服务框架和OSGi没有多大关系，也还是暂且叫着这个名字吧，来看下经历到目前这步后的分布式服务框架是个什么样子了：
从上图中可见，此框架中几乎所有的部分都是可换的，这和OSGi的microKernel思想是非常吻合的，当然，也是为了此框架能更加灵活的满足分布式应用领域的需求。
基于OSGi实现分布式服务框架历程(三)
发布时间:2008年01月22日作者:BlueDavy
阅读次数:146次类别:OSGi、SCA永久链接Trackback
上篇说到，经过分析后决定选用JNDI来实现服务的远程注册、查找和路由，在这篇blog 中就来详细分析下基于JNDI怎么和OSGi结合来实现服务的远程注册、查找和路由。1、远程注册
目前OSGi DS注册时是直接在本地注册服务实例的，要支持远程注册的话首先需要修改DS注册服务部分的代码，在ds的描述中需要增加一个配置项，以支持将服务注册到远程服务中心，例如：
interface="https://www.sodocs.net/doc/f415018671.html,.osgi.opendoc.bulletin.service.WebCommand"/> 在注册时直接采用InitialContext进行注册，不过这里要采取个不同的策略，就是通常jndi注册时绑定的都是实际对象的实例，但要注意，其实在分布式的服务框架体系中，服务是分布式部署的，服务中心仅仅是个注册、路由的地方而已，那么这种情况下只需要把服务的相关元信息注册到服务中心即可，所以这个时候我们会提供一个服务元信息对象，然后把这个元信息对象绑定到jndi上去，这里涉及到的一个问题是jndi 的名称怎么取，这个名称要便于查找服务，同时还得保证唯一性。 可以看出，在这个实现方案中，最重要的就是这个服务元信息对象了，这个元信息对象中应该包含和OSGi服务模型同样的所有的信息，同时还需要包括服务的状态信息，由于包含了状态信息，叫元信息对象的话有点不正确，要么干脆就叫Service或ServiceInfo得了。 2、远程调用 远程调用准确来讲应该分为引用远程服务和调用远程服务两个环节，因为对于lazy init的服务而言首先是远程查找服务，但并不发生调用，所以在这里也分为两步来描述下。 引用远程服务 引用远程服务这块的话JNDI目前的实现肯定是很难满足需求的，按照OSGi的服务模型，在引用服务是只提供了服务的接口名，顶多就是增加了一些服务的特定属性来限定服务的范围，而JNDI在查找绑定的对象时是直接指定名称查找的，一对一的方式，但在OSGi的服务模型中获取到的服务有可能会是多个的，来看看怎么样修改实现这个需求。 首先仍然是修改DS描述，以支持引用远程服务，例如： interface="https://www.sodocs.net/doc/f415018671.html,monDaoService" bind="setCommonDaoService" unbind="unsetCommonDaoService" policy="dynamic" server="jnp://10.100.100.100:1099"/> 在查找远程服务中心的服务时，通过jndi将需要查找的服务的接口、属性等过滤条件传递给服务器端，这个应该可以通过扩展JNDI的lookup来实现，JNDI服务中心接到请求后根据过滤条件从注册的服务中查找到符合条件的服务元信息对象，并返回服务元信息对象集合至调用端，之后由生命周期管理对象决定后续的动作，关于生命周期管理对象在后一个篇章中来详细的分析。 调用远程服务 当远程服务被调用时，此时应该提供的一个配置是是否可跳过服务中心直接向另一端的服务发起调用(某些情况下可能会有这样的需求)，另外就是同步调用和异步调用的配置的支持。 当调用时，可以走某种通讯机制对请求的服务的接口、方法以及参数传递至服务中心或相应的服务提供端，当服务提供端处理完毕后继续走这个通讯机制把处理的结果返回至调用端。经过上面的分析后，可以看出，基于JNDI实现服务的注册、查找不会是难点，在后面一个篇章中开始来分析生命周期的管理的问题，就会比较的复杂了，进入分布式环境后，生命周期的管理就比之前OSGi DS的生命周期管理复杂了很多。 基于OSGi实现分布式服务框架历程(二) 高并发分布式服务架构方案 下图是一个非常全面的架构蓝图，针对不同的应用系统需要的模块各有不同。此架构方案主要包括以下几个方面的设计：数据存储和读取，基础服务，应用层（APP/业务/Proxy），日志监控等，下面对这些主要的问题提供具体的各项针对性技术方案。 数据的存储和读取 分布式系统应该根据应用对数据不同的一致性、可用性等要求和数据的不同特性，采用不同的数据存储和读取方案，主要有以下几种可选方案： 1)内存型数据库。内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格， 适合进行海量数据的存储和读取。例如开源nosql数据库mongodb、redis等。 2)关系型数据库。关系型数据库在满足并发性能的同时，也需要满足事务性，可通过 读写分离，分库分表来应对高并发大数据量的情况。例如Oracle，Mysql等。 3)分布式数据库。对于数据的高并发的访问，传统的关系型数据库提供读写分离的方案， 但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对 于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库HBase有一套完善的解决方案，适用于高并发海量数据存取的要求。 基础服务 基础服务主要是指数据层之上的数据路由，Cache，搜索等服务。 1)路由Router。对于数据库切分方案中的分库分表问题，需要解决在请求对应的数据时 定位需要访问的位置，可根据一致性Hash，维护路由表至内存数据库等方案解决。 2)Cache。对于高并发的系统来讲，使用Cache可以减轻对后端系统的压力，所有Cache 可承担大部分热数据的读操作。当前用的比较多的是redis和memcache，redis比memcache有丰富的数据操作的API，redis对数据进行了持久化，而memcache没有这个功能，因此memcache更加适合在关系型数据库之上的数据的缓存。 3)搜索。搜索可以支持应用系统的按照关键词的检索，搜索提示，搜索排序等功能。开源 开源的企业级搜索引擎主要有lucene, sphinx，选择搜索引擎主要考虑以下三个方面： a)搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高 可用性 b)索引的实时性 c)搜索引擎的性能 Solr是基于Lucene开发的高性能的全文搜索服务器，满足以上三个方面的考虑，而且目前在企业中应用非常广泛。 应用层 应用层主要包括面向用户的应用，网站、APP等，还包括相关的业务处理的运算等。 1)负载均衡-反向代理。一个大型的平台包括很多个业务域，不同的业务域有不同的集群， 可以用DNS做域名解析的分发或轮询，DNS方式实现简单。但是因存在cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在做分发，当然会采用做冗余(比如lvs+keepalived)的考虑，采取主备方式。Nginx是基于事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件，可用作反向代理的工具。 主流分布式系统架构分析 主流分布式---系统架构分析 目录 一、前言 (3) 二、SOA架构解析 (3) 三、微服务( Microservices )架构解析 (7) 四、SOA和微服务架构的差别 (9) 五、服务网格( Service Mesh )架构解析 (9) 六、分布式架构的基本理论 ......................................................................................... 1 1 七、分布式架构下的高可用设计 (15) 八、总结 .......................................................................................................... 1 9 、八、 、 》 本文我们来聊一聊目前主流的分布式架构和分布式架构中常见理论以及如何才能设计出高可用的分布式架构好了。分布式架构中，SOA和微服务架构是最常见两种分布式架构，而且目前服务网格的 概念也越来越火了。那我们本文就先从这些常见架构开始。 、SOA架构解析 SOA全称是：Service Oriented Architecture ，中文释义为"面向服务的架构"，它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立 的形式部署运行，服务之间通过网络进行调用。架构图如下： Appl 跟SOA 相提并论的还有一个 ESB （企业服务总线），简单来说ESB 就是一根管道，用来连接各个服 务节点。 ESB 的存在是为了集成基于不同协议的不同服务， ESB 做了消息的转化、解释以及路由的工 作，以此来让不 同的服务互联互通；随着我们业务的越来越复杂， 会发现服务越来越多，SOA 架构下， 它们的调用关系会变成如下形式: App 2 App 6 App 3 App 4 本文作者Kate Matsudaira是一位美丽的女工程副总裁，曾在Sun Microsystems、微软、亚马逊这些一流的IT公司任职。她有着非常丰富的工作经验和团队管理经验，当过程序员、项目经理、产品经理以及人事经理。专注于构建和操作大型Web应用程序/网站，目前她的主要研究方向是SaaS（软件即服务）应用程序和云计算（如大家所说的大数据）。 本文是作者在AOSA一书介绍如何构建可扩展的分布式系统里的内容，在此翻译并分享给大家。 开源软件已经成为许多大型网站的基本组成部分，随着这些网站的逐步壮大，他们的网站架构和一些指导原则也开放在开发者们的面前，给予大家切实有用的指导和帮助。 这篇文章主要侧重于Web系统，并且也适用于其他分布式系统。 Web分布式系统设计的原则 构建并运营一个可伸缩的Web站点或应用程序到底是指什么？在最初，仅是通过互联网连接用户和访问远程资源。 和大多数事情一样，当构建一个Web服务时，需要提前抽出时间进行规划。了解大型网站创建背后的注意事项以及学会权衡，会给你带来更加明智的决策。下面是设计大型Web系统时，需要注意的一些核心原则： ?可用性 ?性能 ?可靠性 ?可扩展 ?易管理 ?成本 上面的这些原则给设计分布式Web架构提供了一定的基础和理论指导。然而，它们也可能彼此相左，例如实现这个目标的代价是牺牲成本。一个简单的例子：选择地址容量，仅通过添加更多的服务器（可伸缩性），这个可能以易管理（你不得不操作额外的服务器）和成本作为代价（服务器价格）。 无论你想设计哪种类型的Web应用程序，这些原则都是非常重要的，甚至这些原则之间也会互相羁绊，做好它们之间的权衡也非常重要。 基础 1.D ubbo介绍 1.1.简介 Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。 Dubbo最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。 上图中，蓝色方块表示与业务有交互，绿色方块表示只对Dubbo内部交互。上述图所描述的调用流程如下： 1)服务提供方发布服务到服务注册中心； 2)服务消费方从服务注册中心订阅服务； 3)服务消费方调用已经注册的可用服务； 1.2.核心功能 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 1.3.Dubbo能做什么？ 透明化的远程方法调用：就像调用本地方法一样调用远程方法，只需简单配置，没有任何API 侵入。 软负载均衡及容错机制：可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 服务自动注册与发现：不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 是时候设计一个分布式服务框架了。我先将它定名为Hasor-RSF，“RSF”为Remote Service Framework 的缩写。 RSF的目的是为了提供一种高效的远程服务访问方式，例如“A机器访问在B机器上的一个服务”。当然首先它是运行在Java上的，但是我并不希望Java 成为RSF的唯一平台。 它应该是分布式的，就是说服务 A 可能会分布在若干台机器内。当我的应用打算调用这个服务时我应该可以在这若干服务提供的机器上随机调用。这样做的好处是有助于高并发、高访问、高可用。 RSF 的本质其实就是RPC 那么我们可以先对比一下RPC 里都有什么可以被我们拿来选用。下面列出来的只是其中一些我相信聪明的朋友们会列举出更多的解决方案，我也敢保证你们知道的比我还多。 1.Java原生的 RMI。 2.Hessian 3.WebServices 4.Restful 5.HTTP Request 6.RTMP/AMF 7.淘宝的HSF、Dubbo RMI，这个Java 原生的东东似乎从一开始就没有被人们所看好，究其原因是速度太慢。但是它的好处是Java原生，使用RMI 不需要引入其它任何第三方软件包。不过挑剔的同学们似乎不太看好这个优点。 Hessian，原则上说Hessian我并不认为它是一个远程服务框架范畴的东西。我更觉 得 Hessian 是一种数据交互格式。就像是JSON，XML-RPC，AMF，Kryo 一类的东西。Hessian 的优点是大量的兼容平台例如：“IOS、Java、.net、C++、Python、Flash、Ruby、PHP”，其次它的第二个有点是二进制格式。在大对象序列化上会占有很大的优势。 WebServices，一个老牌技术解决方案。在我印象中WebServices 是跟随着SOA 这个东西一起出名的，他有一个最大的好处是防火墙穿透。毕竟人家是靠80 端口吃饭的，牛叉的很。不过话说回来WebServices的最大要害就是，Xml传输格式。把一个对象序列化成为一个Xml数据是一件很容易的事，但是反序列化成本似乎是很高。再加上SOAP 协议本身是建立在XML 形式上，这就使得Web Service 奇慢无比了。当然因素还有很多我就不多说了。 Restful，其实restful 我更觉得它是一种API 表述规范。但在社区论坛中讨论看来，restful 的应用似乎也延伸到远程服务的领域。所以有必要说明一下。restful 最初是出现在web 上，究其本质是还是HTTP。例如对于：“http://xxxxx/xxxx”这个资源的访问可以利用HTTP 的“GET、PUT、DELETE”等方法对资源操作加以描述说明。我个人觉得这东西用在RPC 上并不合适。 HTTP，这是我用过最多的一种远程交互方式。远离很见dna，服务发布者将服务发布成为一个http资源。调用者请求这个http资源。数据传输格式完全程序双方自行协商。这种方法简单除暴行之有效。不过缺点是我们要自己补充通信协议，例如请求参数和响应数据格式。常规的交互格式有JSON、XML。 关于分布式服务框架Dubbo的调研报告 在接触过的项目中由于功能比较少，数据访问量并不是很大，在项目设计架构的时候总是优先考虑如何使代码简化，抽象相似方法。因此会引入诸如面向接口编程，面向切面编程，以及设计模式的考量。此时，ORM(Object/Relation Mapping)的数据访问框架，这种对象关系映射解决了面向对象与关系数据库存在的互不匹配的问题，也成了中小型项目基本的服务框架。其中，我了解的比较多的是显示层的struts2,数据持久层的Hibernate,以及业务逻辑层的Spring,三者通力配合可以大大简化应用服务的代码编程数量，可以让程序员在编写代码的时候优先考量功能需求，而不必为冗余的操作代码而浪费时间，其中我深有体会的有像将服务放入Spring,自动完成事物操作。还有关于CDUR的操作，数据存储与取得，只要进行简单的Hibernate配置就可以直接实现关系对象的转化。 当然以上ORM框架的核心以及它所完成的任务决定了一个项目分层架构是一种垂直纵向的关系，比如说我们经典的MVC模式，我们需要实体层，数据持久层，业务逻辑层，以及显示层。持久层，业务逻辑层，显示层在设计的时候需要从上往下传递数据对象，因而考量设计的重点在于高内聚，低耦合。层与层之间要相互依赖，又要相互独立。这样的设计在进行功能量适中，访问服务数量不多的情况能够应对自如，但是当访问服务数量激增，系统功能变得复杂的时候这种基于ORM的服务架构就会显得笨重，并且不利于测试。 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变得市场需求。那么，提高业务复用及整合的分布式服务框架RPC（Remote Procedure Call Protocol）就成了关键。 这种抽取核心功能的方式非常类似于MVC模型下模板方法模式，即抽取公共方法为抽象基类，而在此处就将相似服务功能抽取出来形成注册服务中心来统一调配资源。 Duboo就是这种分布式服务框架，它主要针对的是一种SOA方案，我们知道面向对象模型是紧耦合的，而SOA指得就是一种面向服务体系，实际上就是我们都认知的面向接口编程，这也是分布式核心思想，尽量用接口定义公共服务 1.问题 1、何为分布式何为微服务？ 2、为什么需要分布式？ 3、分布式核心理论基础，节点、网络、时间、顺序，一致性？ 4、分布式是系统有哪些设计模式？ 5、分布式有哪些类型？ 6、如何实现分布式？ 2.关键词 节点，时间，一致性，CAP，ACID，BASE，P2P，机器伸缩，网络变更，负载均衡，限流，鉴权，服务发现，服务编排，降级，熔断，幂等，分库分表，分片分区，自动运维，容错处理，全栈监控，故障恢复，性能调优 3.全文概要 随着移动互联网的发展智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作工作。计算机以集群的方式存在，按照分布式理论的指导构建出庞大复杂的应用服务，也已经深入人心。本文力求从分布式基础理论，架构设计模式，工程应用，部署运维，业界方案这几大方面，介绍基于MSA(微服务架构)的分布式的知识体系大纲。从而对SOA 到MSA进化有个立体的认识，从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感受如何搭建全套微服务架构的过程。 4.基础理论 4.1SOA到MSA的进化 SOA面向服务架构 由于业务发展到一定层度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯，面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障的时候会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA微服务架构 微服务是真正意义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时增加了整个分布式系统的搭建和管理难度，需要对服务进行编排和管理，所以伴随着微服务的兴起，微服务生态的整套技术栈也需要无缝接入，才能支撑起微服务的治理理念。 4.2节点与网络 节点 传统的节点也就是一台单体的物理机，所有的服务都揉进去包括服务和数据库；随着虚拟化的发展，单台物理机往往可以分成多台虚拟机，实现资源利用的最大化，节点的概念也变成单台虚拟机上面服务；近几年 安装和配置详解 本文介绍的Zookeeper 是以3.2.2 这个稳定版本为基础，最新的版本可以通过官 网https://www.sodocs.net/doc/f415018671.html,/zookeeper/来获取，Zookeeper 的安装非常简单，下面将从单机模式和集群模式两个方面介绍Zookeeper 的安装和配置。 单机模式 单机安装非常简单，只要获取到Zookeeper 的压缩包并解压到某个目录如： /home/zookeeper-3.2.2 下，Zookeeper 的启动脚本在bin 目录下，Linux 下的启动脚本是zkServer.sh，在3.2.2 这个版本Zookeeper 没有提供windows 下的启动脚本，所以要想在windows 下启动Zookeeper 要自己手工写一个，如清单1 所示： 清单1. Windows 下Zookeeper 启动脚本 在你执行启动脚本之前，还有几个基本的配置项需要配置一下，Zookeeper 的配置文件在conf 目录下，这个目录下有zoo_sample.cfg 和log4j.properties，你需要做的就是将zoo_sample.cfg 改名为zoo.cfg，因为Zookeeper 在启动时会找这个文件作为默认配置文件。下面详细介绍一下，这个配置文件中各个配置项的意义。 tickTime：这个时间是作为Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime 时间就会发送一个心跳。 ?dataDir：顾名思义就是Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。 ?clientPort：这个端口就是客户端连接Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。 当这些配置项配置好后，你现在就可以启动Zookeeper 了，启动后要检查Zookeeper 是否已经在服务，可以通过netstat – ano 命令查看是否有你配置的clientPort 端口号在监听服务。 集群模式 Zookeeper 不仅可以单机提供服务，同时也支持多机组成集群来提供服务。实际上Zookeeper 还支持另外一种伪集群的方式，也就是可以在一台物理机上运行多个Zookeeper 实例，下面将介绍集群模式的安装和配置。 Zookeeper 的集群模式的安装和配置也不是很复杂，所要做的就是增加几个配置项。集群模式除了上面的三个配置项还要增加下面几个配置项： ?initLimit：这个配置项是用来配置Zookeeper 接受客户端（这里所说的客户端不是用户连接Zookeeper 服务器的客户端，而是Zookeeper 服务器集群中连接到 Leader 的Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过10 个心跳的时间（也就是tickTime）长度后Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒 ?syncLimit：这个配置项标识Leader 与Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个tickTime 的时间长度，总的时间长度就是2*2000=4 秒?server.A=B：C：D：其中A 是一个数字，表示这个是第几号服务器；B 是这个服务器的ip 地址；C 表示的是这个服务器与集群中的Leader 服务器交换信息的端口；D 表示的是万一集群中的Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于B 都是一样，所以不同的Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。 除了修改zoo.cfg 配置文件，集群模式下还要配置一个文件myid，这个文件在dataDir 目录下，这个文件里面就有一个数据就是A 的值，Zookeeper 启动时会读取这个文件，拿到里面的数据与zoo.cfg 里面的配置信息比较从而判断到底是那个server。 数据模型 Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图1 所示： 分布式服务框架Zookeeper -- 管理分布式环境中的数据 简介：Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。本文将从使用者角度详细介绍Zookeeper 的安装和配置文件中各个配置项的意义，以及分析Zookeeper 的典型的应用场景（配置文件的管理、集群管理、同步锁、Leader 选举、队列管理等），用Java 实现它们并给出示例代码。 安装和配置详解 本文介绍的Zookeeper 是以3.2.2 这个稳定版本为基础，最新的版本可以通过官 网https://www.sodocs.net/doc/f415018671.html,/zookeeper/来获取，Zookeeper 的安装非常简单，下面将从单机模式和集群模式两个方面介绍Zookeeper 的安装和配置。 单机模式 单机安装非常简单，只要获取到Zookeeper 的压缩包并解压到某个目录如： /home/zookeeper-3.2.2 下，Zookeeper 的启动脚本在bin 目录下，Linux 下的启动脚本是zkServer.sh，在3.2.2 这个版本Zookeeper 没有提供windows 下的启动脚本，所以要想在windows 下启动Zookeeper 要自己手工写一个，如清单1 所示： 清单1. Windows 下Zookeeper 启动脚本 在你执行启动脚本之前，还有几个基本的配置项需要配置一下，Zookeeper 的配置文件在conf 目录下，这个目录下有zoo_sample.cfg 和log4j.properties，你需要做的就是将 zoo_sample.cfg 改名为zoo.cfg，因为Zookeeper 在启动时会找这个文件作为默认配置文件。下面详细介绍一下，这个配置文件中各个配置项的意义。 分布式软件体系结构 编写目标： ●面向计算机专业高年级本科生与研究生的教程。 ●可供从事基于Internet/Intranet的分布式软件开发人员参考使用。 要求读者： ●已掌握面向对象程序设计方法与一门面向对象程序设计语言（Java最佳）。 ●具备软件工程的基本知识。 总体构思： ●强调理论与实践相结合：理论上以CORBA 2.4为模型，实践中以VisiBroker for Java 4.0为工具。 ●强调深度与广度相结合：重点介绍CORBA的同时，兼顾DCOM与EJB两种模型， 最后总结对比这三种典型体系结构的特点。 主要内容： ●分布式计算的基本概念：从C/S过渡到分布式体系结构、OMA体系结构、CORBA 基本概念。 ●分布式应用程序的开发：分布式应用程序框架、用IDL编写对象接口、编写服务 程序与客户程序、部署应用程序。 ●分布式计算更深入的课题：探讨分布式应用程序的可靠性、伸缩性、安全性、性能 等课题可能提出的问题以及解决途径。 ●不同体系结构的比较：总结CORBA、DCOM、EJB、XML等特点。 ●配合教学需要的内容：在前言部分提供教学进度供参考，每一章后均配有课后练习 思考题和上机实习题。 引言 分布式计算是当前软件开发技术的一个重要发展方向。C.A.R.Hoare指出：“分布式计算是一个具有重大理论与实践意义的迷人课题，其迷人之处在于理论与实践的同步发展，一方面实践推动了理论，另一方面理论又指导着实践。”本书为读者介绍分布式计算领域的基本概念、开发过程、规范标准等内容。 分布式计算有两种典型的应用途径。第一种应用途径是将分布式软件系统看作直接反映了现实世界中的分布性，例如当今许多业务处理流程通常呈现一种分布式运作方式，负责加工或制造的工厂可能位于珠江三角洲一带，而负责销售与市场营销的部门则可能分别位于北京、上海和广州，这时负责业务流程的软件系统也可作相应的分布式处理。第二种应用途径主要用于改进某些应用程序的运行性能，使它们比单进程的集中式实现更具有效率，此时软件系统的分布性并不是现实世界中分布性的映射，而是为充分利用额外的计算资源而人为引入的。 在计算机硬件技术与网络通信技术的支持下，应用需求驱使计算机软件的规模与复杂度不断增长。面对这种情况，对整个软件系统的体系结构进行分析与设计就远远重要于对算法与数据结构的选择。软件体系结构关心的正是整个软件系统的结构，它决定了一个软件系统由什么样的组件组成，以及这些组件之间的交互关系如何。典型的软件体系结构风格有设计图形用户界面常用的事件驱动风格、操作系统常用的层次化设计、设计编译程序常用的管道与过滤器风格、许多应用程序都会使用的面向对象风格等。 分布式软件系统通常基于客户机／服务器风格，其中客户程序提出信息或服务的请示，而服务程序提供这些信息或服务。客户机／服务器计算模型的发展大约经历了三个里程碑：局域网文件服务器、数据库服务器以及分布式对象。由于当前面向对象技术几乎已渗透到软件开发的每一个角落，先进的分布式软件开发方法当然离不开与面向对象技术的结合，因而分布式软件体系结构通常是客户机／服务器风格与面向对象风格的有效组合，典型的例子有OMG的公共对象请求代理体系结构（CORBA）、Microsoft的分布式组件对象模型（DCOM）、Sun Microsystems的企业JavaBeans（EJB）等。 在这些模型中，CORBA以其规范的严格性、供应商的无关性和其他许多先进的分布式计算特性成为我们教学的首选。在理论教学方面，我们可参考OMG发布的一系列规范和关于CORBA的丰富读物；在课程实验方面，我们既可下载使用IONA Orbix、Inprise VisiBroker 等商品化CORBA产品的30或60天试用版，也可使用OmniORB、TAO等免费CORBA产品。相对于其他分布式计算模型而言，CORBA在理论更为严格与完善，即使读者采用的开发平台未必是CORBA兼容的，CORBA中提出的许多问题也应加以考虑，并可借鉴CORBA 提出的问题解决方案。 本书从软件体系结构的角度介绍分布式软件系统分析与设计的基本概念，描述了分布式软件的开发与布署过程，并探讨分布式软件的可靠性、性能、可伸缩性等高级概念。本书的主要内容分为四个部分。 第一部分“基本概念”介绍分布式计算中的基本概念与基本原理，从客户机／服务器计算模型过渡到真正的分布式计算模型，并掌握OMA与CORBA的基本概念。为避免为传统集中式软件的开发人员一次性引入太多分布式对象计算的新概念，我们需要一个过渡性介绍以实现循序渐进的教学目标，Java RMI以其简单性与实用性自然进入我们的视野。 HSF 初体验 目录 一句话形容HSF 0 HSF安装 0 Ali-Tomcat安装 0 Pandora安装 0 环境配置 0 提供HSF服务 0 创建Web项目 0 添加maven依赖 (1) 编写需要发布的服务 (2) 配置Spring (3) 消费HSF服务 (4) 添加spring配置 (4) 编写测试代码 (5) 打包测试 (5) 实践 (6) 一句话形容HSF HSF就好比人体的血管，它是阿里内部各个系统通信的基础软件。 HSF安装 先了解下HSF应用的运行环境。如图： 首先，应用运行在潘多拉（Pandora）容器中，容器又通过Ali-Tomcat启动。Ali-Tomcat安装 下载并解压Ali-Tomcat即可。 Pandora安装 下载并解压Pandora到Ali-Tomcat的deploy目录即可。 到此，HSF的运行环境就安装完毕。 环境配置 //TODO configserver 绑定 提供HSF服务 创建Web项目 首先用idea（或者eclipse，这里以idea为例）创建一个maven web项目。 File -> New Project -> Maven -> Create from archetype -> maven-archetype-webapp -> 连续Next 项目目录结构如图： 添加maven依赖 在项目pom.xml中添加如下依赖： 主流分布式---系统架构分析 目录 一、前言 (3) 二、SOA架构解析 (3) 三、微服务（Microservices）架构解析 (7) 四、SOA 和微服务架构的差别 (9) 五、服务网格（Service Mesh）架构解析 (9) 六、分布式架构的基本理论 (11) 七、分布式架构下的高可用设计 (15) 八、总结 (19) 一、前言 本文我们来聊一聊目前主流的分布式架构和分布式架构中常见理论以及如何才能设计出高可用的分布式架构好了。分布式架构中，SOA和微服务架构是最常见两种分布式架构，而且目前服务网格的概念也越来越火了。那我们本文就先从这些常见架构开始。 二、SOA架构解析 SOA 全称是: Service Oriented Architecture，中文释义为“面向服务的架构”，它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。架构图如下： 跟SOA 相提并论的还有一个ESB(企业服务总线)，简单来说ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通; 随着我们业务的越来越复杂，会发现服务越来越多，SOA架构下，它们的调用关系会变成如下形式： 很显然，这样不是我们所想要的，那这时候如果我们引入ESB的概念，项目调用就又会很清晰，如下： SOA所要解决的核心问题 ?系统间的集成: 我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范，比如ESB、以及技术规范、服务管理规范; 这一步解决的核心问题是【有序】。 ?系统的服务化: 我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。 ?业务的服务化: 我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从 分布式架构知识体系必读 1.问题 ?1、何为分布式何为微服务？ ?2、为什么需要分布式？ ?3、分布式核心理论基础，节点、网络、时间、顺序，一致性？ ?4、分布式是系统有哪些设计模式？ ?5、分布式有哪些类型？ ?6、如何实现分布式？ 2.关键词 节点，时间，一致性，CAP，ACID，BASE，P2P，机器伸缩，网络变更，负载均衡，限流，鉴权，服务发现，服务编排，降级，熔断，幂等，分库分表，分片分区，自动运维，容错处理，全栈监控，故障恢复，性能调优 3.全文概要 随着移动互联网的发展智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作工作。计算机以集群的方式存在，按照分布式理论的指导构建出庞大复杂的应用服务，也已经深入人心。本文力求从分布式基础理论，架构设计模式，工程应用，部署运维，业界方案这几大方面，介绍基于MSA(微服务架构)的分布式的知识体系大纲。从而对SOA到MSA 进化有个立体的认识，从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感受如何搭建全套微服务架构的过程。 4.基础理论 4.1SOA到MSA的进化 SOA面向服务架构 由于业务发展到一定层度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯，面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障的时候会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA微服务架构 微服务是真正意义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时增加了整个分布式系统的搭建和管理难度，需要对服务进行编排和管理，所以伴随着微服务的兴起，微服务生态的整套技术栈也需要无缝接入，才能支撑起微服务的治理理念。 基于Spring-DM实现分布式服务框架(DSF)(一) 发布时间:2008年01月29日作者:BlueDavy 阅读次数:448次类别:OSGi、SCA永久链接Trackback 经过上篇分析分布式服务框架的blog后，正式对之前的基于OSGi实现分布式服务框架的系列改名(顺便把分布式服务框架改为使用DSF缩写)，因为已经决定基于Spring-DM来实现，为什么呢，而且为什么一定要是Spring-DM，而不直接说Spring呢？ 今天是Spring-DM 1.0 release的大好日子，，不容易呀，做了这么久，具体怎么样还没来得及细看，不过之前有用过1.0 m2，已经觉得很不错了，相信1.0 release更不 会失望。 在我眼里看来，Spring是个很大的东西，其实DSF需要的基础的东西并不多，但又希望保持微核性和扩展性，插件化、具备良好扩展支持的框架无疑是最佳的选择，OSGi无疑是个好的选择，但基于OSGi要自己去实现的东西实在是太多了，Spring-DM则是能满足 我以上两点需求的最佳选择，既有了插件化的框架，又有了很多可用而且是很强大的东西，尤其是Spring在本地调用和远程调用的透明化提供了优秀的设计支持和指导，例如Spring提供的 HessianServiceExporter、JNDIObjectFactoryBean等等，而且Spring 和OSGi结合后，就可以根据需求来选择自己所需的Spring的那些增强功能了，不用每 次都抱着整个巨大的Spring，当然，目前Spring还没完全剥离好，等Spring-DM 1.1后会好很多。 在之前的分析分布式服务框架的blog中，已经说到其实实现DSF简明扼要的说就是：高效的存储、查找策略+高效的通讯策略+满足需求的服务模型+强大的集成能力，其实这里分布式服务架构方案
主流分布式系统架构分析
分布式系统架构设计
分布式服务框架Dubbo及相关组件集成
RSF 分布式服务框架设计
关于分布式服务框架Dubbo的调研报告
分布式架构知识体系
分布式服务框架 Zookeeper -- 管理分布式环境中的数据
分布式服务框架 Zookeeper -- 管理分布式环境中的数据
分布式软件体系结构
HSF分布式开发框架
主流分布式系统架构分析
分布式架构知识体系必读
基于Spring-DM实现分布式服务框架(DSF)