【VMware混合云】掀起你的盖头来 作者：范军 （Frank Fan） 新浪微博：@frankfan7 微信：frankfan7
VMware混合云服务（vCHS）预计在2013年8月23日正式面向用户推出。目前开放服务的四个数据中心都在美国。
我受邀和全球其他15位VCDX/vExpert加入VMware混合云的EarlyAccess Program从而让我有机会能在这位大家闺秀正式亮相之前一睹芳容。
首先什么是混合云。本文所指的云特指IaaS。 PaaS和SaaS的情形以后再谈。
Gartner的定义的混合云涉及到了私有云和公有云的实施及它们之间的整合。通常有以下几种情形。
・本地私有云整合远端公有云
・本地私有云整合远端私有云
・远端私有云整合远端公有云
是不是有点像绕口令？别急，VMware混合云服务属于第一种情形，这是咱们本文的重点。
其次本地私有云整合远端公有云的几个应用场景
场景一：充分使用本地资源，必要时能灵活扩展
某公司的私有云在某个特定时期（比如财政年终，或者推出特别市场推广活动）负荷会比平时高出很多倍，如果完全靠私有云满足，那意味着有很大一部分资源80%的时期是闲置的。
也可以选择平时的负载靠本地私有云，在负荷突然增大时，可以利用在远端的公有云来满足额外的负荷。好处是总体成本比完全的私有云要低很多，而又能利用公有云灵活动态扩展的好处。对于IT部门，可以使用统一的管理工具和流程来同时管理本地和远端的资源。
除此之外，相比企业自建的私有云，一般来说公有云的功能和对需求的响应要好很多。那么对此要求高的应用可以考虑在公有云上实施。
场景二：绝对控制，安全隔离
某公司已经采用了公有IaaS的服务，比如Web服务器和应用服务器都在远端公有云。可是因为安全的顾虑，希望在本地绝对控制数据库，文件服务等资源，同时希望公有云的资源也能和公司的整体安全策略和流程一致。
采用混合云方案可以充分利用了公有云的优势，还能保证本地和远端资源的无缝集成，也满足了安全隔离的需求。更重要的是，本地已经实施的安全策略和流程，可以同样应用在远端公有云上。
简而言之，不管在本地还是远端，IT始终保留绝对的控制权，决定谁能访问什么资源。最终用户的体验也是一致的。可能用户根本不会察觉某些应用在远端运行。其实用户也根本不关心在哪儿运行，只要需求能满足就行。
场景三：灾难恢复/可持续商业应用（DR/BusinessContinuity）
某公司已经在本地有私有云，某些关键业务可用性的要求极高，利用远端的公有云来满足灾难恢复/可持续商业应用的需求，就避免了为此在异地建立私有云的前期高投入、复杂的架构设计以及后期的运营成本。
第三我们来大致勾勒一下VMware混合云服务的特点，具体细节会在后续文章中展开。
无缝集成
VMware混合云依托的是VMware vCloud Director技术，从与本地整合方面来讲，这也是一个得天独厚的优势。因为远端和本地的根本技术架构是一样的，那么已经在本地运行的应用完全可以保证在远端100%成功移植。
统一管理
通过Cloud Connetor或者IPSEC VPN把本地和远端连接起来之后，本地的管理工具，比如vCenter，vCloudDirector Console可以同时管理本地和远端的资源。这无疑让IT的工作轻松了很多。
除了可以使用VMware混合云提供的web管理界面之外，也开放API。第三方可以开发工具管理混合云。
Cloud of Clouds
VMware混合云服务是一个Cloud，而这个cloud内运行有很多CloudInstance，每个instance对于使用者来说都是一个云。所以称此模式为Cloud of Clouds.
第四 对架构师意味着什么？
别总想着怎么自建云服务，多想想怎么用好现成的混合云服务
这也是VMware混合云架构师在一篇文章中提到的主题。他原文的标题更激进一点。虽然我不是100%赞同他的观点，我认为私有云也是有其必然存在的价值,而且混合云和公有云的大规模普及，还需要一段时间。尤其在中国市场而言。
但是他的提醒是值得架构师们特别注意的。
大家知道，云架构是复杂的，需要架构师和整个团队在成本、人力上化大力气。周期长，维护也不易。架构师需要非常有经验，而且考虑到太多方面，难免有疏漏。架构师往往着重注意的是技术架构的细节，比如网卡负载均衡，存储网络优化等等。现在有了VMware混合云，这些东西专家们都给你考虑好了，设计维护都不用你操心，你真正操心的是怎么吃透提供的服务，选择合适的服务来满足你的用户需求。
在设计时要考虑混合的思想
可能你目前仅仅是建私有云，由于各方面条件还不成熟，目前没有使用混合云或者公有云的打算。但是你在架构设计上一定要有前瞻性，混合云的优势明摆着，注意目前的设计不能限制你今后使用混合云方案。
请持续关注VMware混合云后续文章，带您一步步了解细节。
本文出自 "坐看云起" 博客，请务必保留此出处http://frankfan.blog.51cto.com/6402282/1243072
Aspectj 实现Method条件运行 最近我花了半个小时实现了一个Method的按自定义条件运行的plugin，Condition-Run 。实现场景是由于我所工作的客户经常会是在同一个代码集上实现多个Brand，所以有些功能只会限制是几个brand调用，而其他的调用则不该调用。还有因为持续交互，我们会不停的release新的功能得到快速的反馈，在这前提下我们会经常遇见在我们刚开发完一个brand的产品代码，就要面临release，所以我们希望其不该对其他的brand产生影响。
面对这样的需求初级程序员有些人肯定会觉得没什么了不起的啊，不就是几个if/else或者switch/case。我和我的团队对代码有一种天生的洁癖，对于太多复杂的if/else和switch/case，以及将来会被移除的临时非产品代码分布在各处，有一种抵触心理。
对于有一定工作经验的程序员来说这样的需求肯定也不是什么问题，不就是AOP（面向切面编程），对，这就是我们所期望的解决方案，把处理的逻辑集中，和产品代码的分离。
知道了用AOP，也许你只对了一半，在AOP的世界里，有两种实现方式静态植入和动态代理，最早了AOP实现采用的是静态植入，然后由于IOC之类的框架的兴起，动态代理的实现方式也逐渐兴起，取代了静态植入的方式。但并不是说静态植入的方式就不再有用武之地的，在这里我们所采用的AOP框架Aspectj就是一个静态注入的框架，我们并没有和spring结合，动态代理的方式有个基本的问题就是你不能直接new这个对象这需要交给框架处理，如果是spring框架的话，这要求你必须是一个spring的bean，以及动态代理会有一些性能的损失。这对于该场景的限制太多，并不是我所期望的。
静态植入的框架在我以前的博客中也提到不少，如果感兴趣请移步 《IOC/AOP随笔目录》。在java世界里Aspectj，.net世界里PostSharp（博客中静态植入原理分析篇《MSBuild + MSILInect实现编译时AOP之预览》）就是这类框架。
回到主题，对于 condition-run如何使用请移步github文档。
这里简述如何实现：
1 对于AOP第一步是匹配规则，所以定义一个标记：
@Retention(RUNTIME)
@Target({METHOD})
public @interface ConditionRun {
Class<? extends Runner> value();
}
其指向一个实现Runner接口的类型。
2：有了匹配规则，我们就可以找到切入点进行AOP逻辑的处理，
@Aspect
public class ConditionRunAspect {
@Around("methodsToBeConditionRun(conditionRun)")
public Object profile(ProceedingJoinPoint pjp, ConditionRun conditionRun) throws Throwable {
final Result result = isExec(pjp, conditionRun);
if (result.isExec()) {
return pjp.proceed();
}
return result.getDefaultValue();
}
private Result isExec(ProceedingJoinPoint pjp, ConditionRun conditionRun) {
try {
final Runner runner = conditionRun.value().newInstance();
final MethodSignature signature = (MethodSignature) pjp.getSignature();
return runner.exec(signature, pjp.getArgs());
} catch (Exception e) {
throw new RuntimeException("Runner must be empty constructor and make sure the config is ok.", e);
}
@Pointcut(value = "@annotation(conditionRun)")
public void methodsToBeConditionRun(ConditionRun conditionRun) {
}
}
这里在切入方法调用之前，new了一个配置的Runner类型（注意必须午餐构造），并调用其exec方法获取是否运行该方法，如果不运行则返回什么默认值。
Runner runner = conditionRun.value().newInstance();
final MethodSignature signature = (MethodSignature) pjp.getSignature();
return runner.exec(signature, pjp.getArgs());
exec的参数签名为方法签名信息和方法运行时参数。
一切都这么简单，现在你可以任意的框架Runner去做适合你的场景业务了。可以参照项目下得sample实例，该实例展示了一个当出入参数为3的时候执行，部位3则返回默认值1.
想想还有那些场景，你是否遇见过某类单元测试我只希望运行在某种固定的场景下？假设在开发图形应用的时候，我们希望调用一些不同平台的特定api，虽然我们代码设计封装做得很好，但是我们希望有固定的集成测试去cover这部分逻辑，让我们的测试只运行是固定平台。
本文出自 "破狼" 博客，请务必保留此出处http://whitewolfblog.blog.51cto.com/3973901/1242894
没有评论:
发表评论