云架构在甲方的落地之路-架构背景篇(2)

在上一篇云架构在甲方的落地之路-架构背景篇(1) 的文章中， 我介绍了在云架构开发前期所需要做的一些准备工作。更多的是了解业务驱动，IT战略，成熟度评估，并定义了架构原则。从一个做技术角度来看这些好像都很虚，但是从一个甲方管理层角度来说这些“虚”的东西往往更好的可以讲出一个故事，也正是这些“虚”的东西为之后的“实”在战略层面打下了扎实的基础。

那么在这篇文章中我们就要着重讲一下我眼中的云架构愿景。另外再次强调的是，由于个人经验以及篇幅的关系，案例主要都是以微软公有云落地作为项目背景。

 

架构愿景阶段：

 

1. 项目的建立。

一般来说，一个云架构在大中型企业中都是通过项目的方式来落地的。笔者所待过的外企都会有自己的一整套项目管理体系，基本上都是由PMP或者Prince2定制裁剪出来的产物。当然近些年也会有类似于敏捷的方法论，但是个人认为云架构的项目并不完全适合于敏捷。

如果公司里并没有成熟的项目管理体系，那至少也要有基本的项目管理常识，把握基本的要素和流程，并对项目进行整体把控。这里也推荐所有的甲方IT从业人员至少都去学习一下PMP, 否则别人说到项目一些最基本的名词也能让你听的云里雾里。

 

2.识别利益相关者

识别利益相关者无论是在项目管理还是在架构开发都是无比重要的一环。因为他们的关注往往会决定你最后的架构输出。

一般来说云架构的利益相关者更多的会是应用部门，应用架构师，运维团队，相关的管理层或者global的相关人员。

除了识别之外，也要了解每一个利益相关者的权利以及利益级别，因为干系人越多，你就越是难以做到让所有人都满意，这个时候就需要有取舍。举个例子，如果一个人即不是位高权重，最终架构对其本身可能影响也不大，那即便他再怎么喜欢表达其独特的关注，你也不必花太多精力。在某些时候甚至都不用做到对齐知会，只要最后直接给到结果就行。

 

3. 确定IT战略以及约束条件

在做云架构时IT的整体战略以及业务的需求在着手设计之前就必须确认。云的架构模式有许多种，因此并没有绝对的正确或者错误，只有合适与否。就像你嫌弃的相亲对象可能在别人眼里就是块宝一样的道理。这里至少要决定以下几点：

---公有云，私有云还是混合云。

决定依据一般是看预算情况，合规要求，业务数据的类型以及敏感程度。

---单数据中心还是多数据中心

主要依据预算以及应用的业务连续性要求。

---单云还是多云

主要依据不同云平台技术组件上的差异以及应用本身对平台的依赖性。

---用哪一家或几家云厂商

参考单云还是多云的依据另外加上所用到服务费用的对比，厂商的资质，以及global的选型标准

 

4. 评估能力

评估目前企业的人员能力。比如如果你的技术团队有对Azure或者AWS更加熟悉，那在选云厂商的时候可以向这方面靠拢，在选partner的时候也可以参考其对应的MSP列表

 

5.定义范围。

这里的范围就是你架构项目要涉及的领域了。要明确哪些是在你的基线以及目标架构的范围之内。一般来说一个infra层面的云架构至少要涵盖以下几块：

• 整个云平台的管理
• IaaS--涉及包括网络，虚拟机，存储等
• PaaS--自动化，应用和数据库相关的组件服务等
• 安全---平台安全（授权认证），主机安全，应用安全，边界安全等
• 业务连续性--备份与恢复，灾备
• 监控告警
• 日志审核分析

如果整个架构项目涉及到应用，中间件，数据交互，那就需要和应用架构师以及应用团队一起align其他具体的领域。

 

6. 确认架构原则

在开发架构愿景之前，再次确认在准备阶段定义的架构原则是否足够明确。如果依然有歧义或者模棱两可的原则，则需要及时返工重新定义。

 

7.开发架构愿景

做了那么多的准备工作，重于到了技术干货的时间了。不过在这里也只是一个开端，所输出的只是架构定义的0.1版本，也就是high level 的draft。

在这里就要用到一个很重要的东西就是业务场景。你也许会问，我一个做infra的哪里来需要考虑的业务场景啊？

就像我之前说的，你面对的所有住在云上的应用全部都是你的客户，即便是IT自己的内部客户，也必定是有对应的业务场景，只不过在我们这里叫做应用场景。而这些业务场景很多都会与之前的一些干系人的关注，IT战略，限制条件联系在一起。这里我就以Azure为例，据几个例子。

---如果你所在的集团公司有多个BU，而作为各自的BU的IT都希望自己能独立管理自己的服务这样可以更好的相应各自业务的需求

在这种场景下，你可能就需要考虑是否需要用多订阅授权的方式来搭建基于Azure的云平台。

---作为业务部门重要的订单系统，需要和公司内部的SAP系统进行数据交互，并需要保证网络稳定以及连续性

了解Azure的同学们应该知道在这种情况下，你的第一反应往往就是ExpressRoute+S2S VPN。ER的整体费用其实并不低，也正是有了对跨网传输稳定性和性能的高要求，一般才会考虑这样的方案。

除了来自业务场景的需求，在整体设计云架构时也要有特定的优先考量。以azure为例，在具体到技术细节之前，以下几个问题必须首先确认，否则在日后应用上线再做修改将花费极大的人力和物力：

• 订阅的管理模式

当下比较多的订阅管理模式无外乎以下几种：

单订阅统一管理

不同业务单元/部门各自订阅

生产和测试环境订阅隔离

不同的项目各自订阅

从一个外行人的角度来看，好像四种模式中除了第一种之外其他的都是比较合理的分法。可惜的是，在我接触过infra管理体系比较强的公司中，绝大多数反而都是单订阅管理。

从环境隔离和资源的权限管理来说，分不分订阅其实并没有太大的差别。不同订阅的IaaS, PaaS资源在不做ACL的情况下依然可以通过azure 公共网络进行互通，而权限可以通过RBAC控制在资源组层面达到同样的效果。多订阅最直观的好处只有两个---分账更直观以及不同BU/部门的自主可控。如果你能利用好资源组和标签，资源分类其实根本不是问题。因此多订阅的情形一般也就在第二种比较多，主要就是为了划清各自的边界。

个人不推荐不同项目各自订阅，一个是在IaaS层浪费IP资源，其次环境各自过于独立不便管理，项目一旦多起来就异常凌乱。另外单订阅的情况下，你也可以单独再搭建一个订阅作为新功能的学习测试，类似于IT部门自己的sandbox环境。

 

• 网络的基本模式

这里不多做比较，最推荐一种模式，也是大多数企业经常用到的: hub-spoken网络架构

有一个核心VNET作为hub连接其他对外VNET以及本地网络。这种设计符合了传统的内外网隔离安全要求，并且最大化利用了你infra的一些管理服务比如补丁，监控，备份，防病毒。也可以集中对流量进行控制。自从中国azure的global peering上线之后，即便在不同区域不同订阅下的VNET都可以做到对等互联。因此这样的设计从任何一个角度来看都是百益而无一害。

除以上两方面之外，其余的设计即便在之后有所修改，变更的成本也不会特别大。另外在这个阶段你更多的是要考虑需要哪些服务，以及是用云平台自带还是第三方集成。这里举几个例子供参考：

---WAF，你可以用相对成本较低的Azure Application Gateway，也可以在azure market利用第三方镜像自建IaaS WAF，甚至可以购买第三方SaaS服务例如CloudFlare。但无论如何你都要自己心里有一个底，比如都至少要支持到OWASP 3.0。

---备份，azure平台本身就有MARS,MABS, Azure IaaS backup 等多种备份方案，能满足大多数应用场景。你也可以集成第三方的一些服务来应对一些特殊的要求。

---监控，Azure本身就有Azure Monitor来监控云上的资源。你依然可以结合一些IaaS的传统监控软件来强化你的监控体系，从免费开源的Zabbix，到成熟的商业产品Solarwind，以及最近比较火的Prometheus。如果你想做到应用层面的颗粒化的性能监控排错以及优化，可以考虑Dynatrace。性能越是强大的监控产品相对的费用也就越高，如果你想把重要如ERP系统搬到云上，就不要过于在乎监控层面的成本。比起你一套几千万的SAP，那些的成本真的是九牛一毛，而且强大的监控产品也会对你日后的排错优化有着极大的帮助。

---日志分析。最近security center以及log analytics 在中国区发布后极大程度上弥补了这方面的短板，但是如果你需要更全面的日志分析，集成第三方方案也是必不可少。

以上几个例子只是用来制定一个high level的框架，具体的技术细节还要在架构定义中深入挖掘分析。另外虽然我例举了一些业内常用的产品，但是在这个阶段你并不一定要确定最后的选型，更重要的依然是在架构中定位好所涉及到服务的要求。

 

8.识别风险以及缓解措施

在任何项目中都会有风险存在。除了项目中经常会遇到的经费不足，项目交付时间不足等，一个云架构最多出现的风险往往是你画的visio天马行空结果在落地过程中发现技术层面实现起来非常困难，日后的维护也耗时耗力。

这里单就这个问题提一下我个人的见解：

一个架构或者方案一般设计由Architecture Team完成，落地部署由Engineering team搞定，日后的维护有operation team去做。如果有幸这三个role其实是你一个人，那就是自己挖的坑你自己给填上，可能会有一些第三方的vendor协助你完成，但技术层面必须要你自己把关。最忌讳什么都让vendor自己协商，最后的结果往往就是啥都搞不定。如果公司的分工比较明确，那架构师在做架构过程中尽早involve其他的team，可以提前识别一些风险和问题，并可以更早的找到缓解措施。

碰巧最近看过一部国产片“筑梦情缘”，其中就是有一个桥段，设计师在设计建筑图纸的时候由于没有工地的具体实施经验，结果设计出的图纸没有考虑到当时施工难度，结果就是工头就当场罢工直接指责设计师啥都不懂只会坐在办公室画画图，最后的结果也是图纸打回去重新设计。

用现在DEVOPS的思想就是把开发和运维团队放在一起做到无缝衔接，这个在云架构方案落地时也会很有帮助，从不同角度看待问题，往往会给你不一样的收获。

 

9.开发工作说明并批准项目

这一点更多是从项目角度确定和批准SOW，根据每个公司各自的要求流程完成即可。

 

到这里整个架构背景就介绍完成，之后我会开始详细的讲架构定义的一些细节，技术层面的分享也会更多一些。同时也非常欢迎大家留言讨论。

原文地址：https://www.cnblogs.com/tenghaohua/p/11167389.html