如何快速构建中小企业应用上云架构的应对思路

Posted 2020-10-01

好久没来了，这段沉浸的时间都在专注学习云计算相关的解决方案和进行实战，这一次更新那当然是有项目在个人的努力下，落地了！！！！

所以过来更新下，我在项目中的各个状态。当然仍然是用第一视角的去解读，这也是一次汇总和回顾，有很多主管的想法在里面，不喜勿喷。

先在“上菜”前，开放的聊聊我个人理解中的云计算是什么样子的？到底什么样的业务部署形式才属于真正的云计算部署？到底我们在云计算这样的趋势下如何合理运用好云计算的特点去提交合适的技术解决方案？

首先，我个人的总结了几点：

1. 改变了传统IT运营交付模式，减少了传统IT对网络高级工程师需求，降低对运维团队的投入。

2. 动态弹性调整，按需使用，按量付费。完全灵活自主，若企业过于庞大，预算控制等相关IT治理流量冗长，对于业务团队开发效率是致命打击。无法很好的控制预算申请额度，还要考虑传统的设备利旧等等问题，接踵而至的管理上的问题，都是传统IT治理中无法避免的。在企业应用上线初期保证业务系统架构和IAAS架构高可用的情况下，可以用最低的资源配置让业务快速上线进行demo的环境的ready，等待业务经过压力评测后，在平滑的进行资源配置提升。在成本控制上也是boss非常乐意看到的。

3.DDOS攻击的包袱、IT基础资源的硬件维护投入（每年维保服务）、机房的风火水电维护、中国多家运营商之间的异网传输问题，应用和网络安全的的包袱。都可以扔掉，完全交给专业的运营商去解决。
综上，所以云计算带来的“革命”一定是新鲜互联网企业和软件开发商（ISV）的必选。无论是从运营角度还是技术对接难度难度上，云计算均是无懈可击之势，所以搞清楚客户的准备上云的系统应用非常重要，这个可以做为一个突破点，去了解其他的应用。然后慢慢引导上云。一定会双赢

好了，上菜，上菜！！！！！！

项目背景：

简述,客户考虑上一套物联管理系统，涉及消防系统、门禁等传感信号管理，管理员可以通过手机app、客户端管理终端等方式管理   

1. 客户属于国资背景    

2. 企业应用属于物业管理系统性质    

3. 无任何新旧数据过渡的“负重”，完全新的系统上线

项目经过：
大家能明白，做售前或者架构师，一定是销售机会现行，那就一定是sales先接触到最终客户。那这个时候我一般会先找到对应的sales，先聊聊客户的情况，通过什么方式找到的？对方是CIO还是CTO，还是engineer。总结一句话，先弄清自己面对的对象是谁，再去考虑怎么去设计方案和沟通。

进行了一些沟通后，确认了对方角色，公司名称。随后进行了一些百度了解。

这里再唠叨一句，我们有很多冲售后走向售前的工程师，特别容易犯的意识形态错误，会先去想这个技术怎么落地，自己有没能力做？不会去关注即将面对客户是谁？总结一句话，如果你从幕后走向业务前端，一定务必先搞清楚你的客户（博弈的对手）是谁。
我还是像之前的一样，用个人的视角去阐述自己的处理经过，当然中间有很多观点均是个人主观出发，若感觉比较偏激或偏执愿意与笔者交流讨论，留言给我噢，若觉得没有什么必要，直接往下看正文略过即可。

第一次电话沟通-【需求沟通&设计阶段】：
在去客户现场前一天，我通过sales，我与客户进行了基于阿里云的产品第一次沟通，沟通了应用场景、软件情况、高可用等思想。可以说是一聊就明白了，非常顺利。

接着晚上加班整理了架构方案，架构图如下：

方案一

方案二

方案三

这里一共提供了给客户了三种架构构建方案，关于ucloud暂时没有给出，因为发现ucloud的云产品-负载均衡在某些地域没有，这个局限性比较大，就直接忽略了。

PS：因涉及三个产商对标的情况，涉及一些竞争，我这里不透露，大家自己去琢磨吧，哈哈

注意，这里是此篇文章分享的重点，我们在第一次面对沟通中，客户提出了不少技术上的挑战，当然你会想，就这么点产品，哪会有什么挑战？

第二次面对面拜访洽谈-【方案确认&可信性对接】：
这里先说说下前面设计的方案的思想：web无状态，统一存储、数据库分离部署

挑战：
1. 软件商目前告知数据库、文件存储不可拆分部署
2. 软件未在负载均衡环境下测试过，需要测试
3. 腾讯云、阿里云、ucloud的产品优劣势对标

因客户最终比较偏向于阿里云，所以这里给大家稍微提一下阿里云的产品的知识设计出于的考虑。

前端：WAF（应用防火墙）+SLB（负载均衡）+ECS（无状态云服务器）
后端：RDS（云数据库）
文件存储：NAS文件存储
网络：VPC（虚拟私有网络）+NAT网关（解决ECS出局流量）

当我们在部署的SLB后，对于后端私有网络VPC中的ECS，ECS是不具备主动出去访问的能力。

注意看我如下的流量走向示意图，SLB到ECS这段，因为在阿里云内部，我们会选择在SLB上设置后端监听ECS一定是内网IP处于对。这样同时也可以保证安全。

故根据以上的判断如下：

1. 在SLB中的ECS是无法主动对外访问ISP资源，只能通过其他方式去实现。可以这样理解。
2.，SLB只做了DNAT的功能，SNAT的功能他不负责，这个在传统的F5设备上其实是可以做的，这一点要注意。

3. 所以要找到一个可以解决SNAT的产品，NAT网关就是一种，当然也可以利用ECS去自建iptables去解决，只需在VPC内把缺省流量扔到对应的主机上即可。

在得知客户说数据库拆分和文件存储不可拆分时候，我倒是一点都不担心，因为在做过一些系统集成单子的售前都明白，在系统架构中，数据库调用也都是依靠IP地址，文件存储是依靠路径。只是以往我们放在一台设备上，就无需考虑这些事情。

关键点一：

这里是帮助客户说服软件提供商，拆分的事情也可以做的，不是不能做。所以除了你要了解一些系统底层常规的结构之外，还要清楚一些拆分后给软件开发（程序员）带来的问题。

所以我们与对方的程序员工程师进行了一通电话沟通，并进行了详细的“技术实现推演“，在大概30分钟左右的沟通后，显然对方已经败下阵来。认可了我的方案提议。

关键点二：

大家注意，这里我解决的不是这个技术实现问题，是解决了目前这个客户和软件商之间的问题。相当于你可以理解，我是甲方的工程师，我代替甲方去“challenge”软件提供商。那换来的自然是客户的信任和好感。所以大家在后面支持客户上云时候，没条件也要去想办法创造条件去弄清楚客户的整个IT架构中的组织架构。这个对于后期开展工作非常重要！！！注意

比如：有多少个软件供应商、有哪些运维人员、多少人是外包的等等。

关键点三：

解决了技术问题，解决了商务问题，那还有什么可以说的呢。当然有的说，这个时候就要问客户的项目预计上线时间、二期扩容计划、整体项目预算大概在多少数量。——————这一点为什么要问，大家自己体会吧，有时候感觉自己太白话也不好。

然后，因为我个人不抽烟，来客户公司前，看见客户在抽烟。所以就在提议结束的时候，让销售陪客户出去抽抽烟，瞎聊聊。我留下来整理下信息。至此第一次拜访结束。

第三次客户来我们公司洽谈-【方案计划实施阶段】
在第一次会议后，我们将相关资源配置报价方案给到了客户后，客户主动约到我们公司详细谈方案价格方面的事情。

在来了后，我们直接进入到商务合同的确认事宜，所以我给上次拜访下了一个成功的结论。

这里，大家应该很清楚，基本上这个项目已经八九不离十了，所以这里只要保持好标准的推进节奏即可，无需担心丢单的问题了。

不过在这里同样也出现了一些小问题，比如客户对云上的产品不熟悉，就会出现各种部署细节上的一些疑问。所以这里需要扮演原厂的工程师提供一些支持，这个对于售前的能力考验很大，因为售前一般都会比较偏框架的设计，很难有心思去关注到实施细节上。

例如：
1. SLB上的会话保持怎么做？它四层转发和七层转发是否可以共存。
2. ECS部署后，如何快速起一个http服务测试SLB的效果。
3. RDS上如何连接并导入demo-DB进行测试。
4. 对于测试和验证是否有详细的测试报告。
5. 。。。

例如：SLB如何配置，如下图的操作截图。

注意这里！！！！如果一个架构师仅仅是做好技术解决方案一定是不行，要善于发现客户的“痛”！！

其实，当客户问到我这些问题的时候，我第一时间想到的不是如何回答！！！而是立刻想到了一问题，客户可能遭遇到了来自公司高层的一些“challenge”，因为客户对公司IT整体负责，那自然会涉及到像“述标”的情况。我想到是客户遭遇到这些，自己无法很快的顶过去。所以此时我已经做好持久解决和复习学习的心里准备。

    一、是复习自己对产品的认知
    二、是帮助客户在内部站住脚跟
    三、是引导客户在哪里可以找到解决文档方面的工作的案例文档

好了，今天就暂时先分享到这里，因为一篇好的文章，往往几千字是说不完的。所以我后面会继续分享，分成【业务上线的项目管控与跟进】等部分去展开。期待各位读者持续关注本博客。

目前正在进行对一些传统IDC的方案向云计算方面转化，后面会持续分享项目工作心得。感谢各位的细细评味。

我的初心一直是这样，我在尝试着真诚地描述自己遇到的问题和解决经历。若你也是一个在技术路上坚持的人儿，那就一起加油，一起努力。
                                    ———来自一个正在努力读书的网工Allen

QQ:549675970
QZONE:http://user.qzone.qq.com/549675970
E-mail：
          [email protected]
          [email protected]
人生格言：越努力、越幸运

本文出自 “Allen在路上-从零到壹” 博客，转载请与作者联系！