Dubbo服务治理了看法
当我们现有ITOO平台系统的业务随着用户的逐渐增大，设计的业务越来越广，系统会异常的复杂，在大规模服务之前。我们能够採用的是RMI或Hessian等工具。暴露和引用远程服务，通过配置URL地址和JNDI地址进行调用，使用Apache httpd复杂均衡插件或F5server进行负载均衡
存在下面问题和怎样解决呢？
当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
此时须要一个服务注冊中心。动态的注冊和发现服务，使服务的位置透明。
并通过在消费方获取服务提供方地址列表。实现软负载均衡和Failover。降低对F5硬件负载均衡器的依赖，也能降低部分成本。
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描写叙述应用的架构关系。
这时。须要自己主动画出应用间的依赖关系图，以帮助架构师理清理关系。
接着。服务的调用量越来越大，服务的容量问题就暴露出来。这个服务须要多少机器支撑？什么时候该加机器？
为了解决这些问题，第一步，要将服务如今每天的调用量。响应时间。都统计出来，作为容量规划的參考指标。
其次，要能够动态调整权重。在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的訪问量，再以此訪问量乘以机器数反推总容量。
规模继续扩大，应用之间不再是扁平的相应关系，開始分层，比方核心数据层，业务集成层等，就算没有出现循环依赖。也不同意从低层向高层依赖，以免兴许被逼循环依赖。
这时。须要在注冊中心定义架构体系。列明有哪些层的定义，每一个服务暴露或引用时，都必须声明自己应用属于哪一层。这样注冊中心能更快的发现架构的腐化现象。
服务多了。沟通成本也開始上升，调某个服务失败该找谁？服务的參数都有什么约定？
这时就须要登记每一个服务都是谁负责的。并建立一个服务的文档库，方便检索。
慢慢一些敏感数据也都服务化了。安全问题開始变得重要。谁能调该服务？怎样授权？
这种服务可能须要一个password。訪问时需带着此password，但假设用password，要改password时，就会非常不方便。全部的消费方都要改，所以动态生成令牌(Token)可能会更好，提供方将令牌告之注冊中心，由注冊中心决定是否告之消费方。这样就能在注冊中心页面上做复杂的授权模型。
就算是不敏感的服务。也不是能随意调用。比方某服务突然多了一个消费者，这个消费者的请求量直接把服务给拖跨了，其他消费者跟着一起故障。
首先服务提供方须要流控，当流程超标时。能拒绝部分请求，进行自我保护。
其次，消费者上线前和提供者约定《服务质量等级协定(SLA)》。SLA包含消费者承诺每天调用量，请求数据量，提供方承诺响应时间，出错率等，将SLA记录在监控中心，定时与监控数据对照，超标则报警。
尽管有SLA约定，假设不能控制。就仅仅是君子协定，怎样确保服务质量？
比方：一个应用非常重要，一个不那么重要，它们调用同一个服务，这个服务就应该向重要应用倾斜，而不是一视同仁，当支撑不住时。应限制不重要应用的訪问。保障重要应用的可用，怎样做到这一点呢。这时。就须要服务路由，控制不同应用訪问不同机器，比方：
应用分离：consumer.application = foo => provider.host = 1,2,3consumer.application != foo => provider.host = 5,6读写分离：method.name = find*,get* => provider.host = 1,2,3method.name != find*,get* => provider.host = 5,6
服务上线后，须要验证服务是否可用。但因防火墙的限制。线下是不能訪问线上服务的，不得不先写好一个測试Main，然后放到线上去执行，非常麻烦，而且容易忘记验证。
所以线上须要有一个自己主动执行的验证程序，用户仅仅需在界面上填上要验证的服务方法。以及參数值和期望的返回值。当有一个服务提供者上线时，将自己主动执行该用例，并将执行结果发邮件通知负责人。
服务应用和Web应用是有差别的，它是一个后台Daemon程序，不须要Tomcat之类的Web容器。但因公司之前以Web应用为主，规范都是按Web应用的，所以不得不把服务跑在一个根本用不上的Web容器里，而搭一个这种Webproject也非常费事。
所以须要实现一个非Web的容器。仅仅需简单的Main载入Spring配置就可以，并提供Maven模板project，仅仅需mvn dubbo:generate 就可以创建一个五脏俱全的服务应用。
开发服务的人越来越多，更注重开发效率，IDE的集成支持不可缺少。
通过插件，能够在Eclipse中直接执行服务，提供方能够直接填入測试数据測试服务。消费方能够直接Mock服务不依赖提供方开发。
由于暴露服务非常easy，服务的上线越来越随意。有时候负责服务化的架构师都不知道有人上线了某个服务，使得线上服务鱼龙混杂，甚至出现反复的服务，而服务下线比上线还困难。
须要一个新服务上线审批流程，必须经过服务化的架构师审批过了，才干够上线。而服务下线时，应先标识为过时。然后通知调用方尽快改动调用，直到没有人调此服务。才干下线。
因服务接口设计的经验一直在慢慢的积累过程中，非常多接口并不能一促而蹴。在改动的过程中，怎样保证兼容性。怎么推断是否兼容？另外，更深层次的，业务行为兼容吗？
能够依据使用的协议类型。分析接口及领域模型的变更是否兼容，比方：对照加减字段，方法签名等。
而业务上。可能须要基于自己主动回归測试用例，形成Technology Compatibility Kit (TCK)，确保兼容升级。
随着服务的不停升级。总有些意想不到的事发生，比方cache写错了导致内存溢出，故障不可避免，每次核心服务一挂。影响一大片，人心慌慌，怎样控制故障的影响面？服务能否够功能降级？或者资源劣化？
应用间声明依赖强度。哪些功能强依赖，哪些弱依赖，然后基于依赖强度，计算出影响面，并定期測试复查。加强关键路径上的服务的优化和容错，清理不该在关键路径上的服务。
提供容错Mock数据。Mock数据也应能够在注冊中心在执行时动态下发。当某服务不可用时，用Mock数据取代，能够降低故障的发生，比方某验权服务。当验权服务全部挂掉后，直接返回false表示没有权限。并打印Error日志报警。
另外，前端的页面也应採用Portal进行降级，当该Portal获取不到数据时，直接隐藏。或替换为其他模块展示，并提供功能开关，可人工干预是否展示，或限制多少流量能够展示。
当已有非常多小服务，可能就须要组合多个小服务的大服务，为此，不得不添加一个中间层。暴露一个新服务，里面分别调其他小服务。这种新服务业务逻辑少，却带来非常多开发工作量。
此时，须要一个服务编排引擎，内置简单的流程引擎，仅仅需用XML或DSL声明怎样聚合服务。注冊中心能够直接下发给消费者执行聚合逻辑，或者部署通用的编排server。全部请求有编排server转发。
并非全部服务的訪问量都大，非常多的服务都仅仅有一丁点訪问量，却须要部署两台提供服务的机器，进行HA互备。怎样降低浪费的机器。
此时可能须要让服务容器支持在一台机器上部署多个应用，能够用多JVM隔离。也能够用ClassLoader隔离。
假设你的应用是国际化的，有中文站，美国站之类，由于时差，美国站的机器晚上闲的时候，可能正是中文站的白天忙时，能够通过资源调度，分时段自己主动调配和部署两方应用。
以上是提给我和大家学习Dubbo同事们的问题，通过Dubbo的使用来深入浅出的领悟吧。
版权声明：本文博主原创文章。博客，未经同意不得转载。