有些日子没有整理案例了，回顾了下上次案例分享的日子，已经有将近四个月了。。
~~~~~~~
从开始在51CTO上写架构师服务这个系列后，因为留了联系方式后，有不少志同道合的的朋友留言、加好友对一些特定的场景进行交流，其中个人收获并纠正了不少错误的观点。无论如何还是要谢谢有这么个地方，让我去记录并分享个人的一些经验和心得。
~~~
又脱更这么久了，抱歉抱歉~~~（读者：“信不信我把你按着地上摩擦~~！！”）
最近确实忙着很多连续性的工作，但都不是具体配啥了，让各位失望了~~~：），如我前面几篇文章提到的，确实当“技术方案”推进到一定的阶段后，有很多时候并不会让你接着像以前本地接console、远程SSH去调试了。。（当然你读者要是纯支撑运维部门的一员的话，直接忽略我的观点，：）），那多出来的时间都去干嘛了呢？
很显然是，“设计方案、规划实施交付过程、学习业务、业务运行逻辑、开发调用过程~~”
这不，有一个好的机会遇到了一个全球运动品牌的Top5企业。这个项目由比较幸运的我来配合做了。摆在眼前的挑战是“完全新的公有云环境、新的PAAS特性、新的Docker运行环境、新的交付逻辑以及全英文的沟通环境”。着实让人兴奋~~~，我在官网找个案例讲讲这个项目大概痛点在哪里？如下图所示；
图（一）
如上图所示：
在最右边图上有个不起眼的地方标注了：“OLAY专柜及天猫旗舰店积分权益共享”。现在越来越多的传统零售企业，选择在国内一线TO C/B的电商平台上注册并运营自己的店铺。因为类似阿里巴巴（天猫）这样的平台，已经成为了“国人”不可或缺的购物平台选择，业务上天猫能带来非常多的流量，例如：六一八、双十一、双十二，这也是后面我会谈到的“流量红利”。
类似天猫平台的还有很多，比如苏宁、京东等。而且京东云的也已经在零售行业开始发力。
PS：找个时间我会单独写一篇文章带各位认识下京东的“零售能力”。
但如果我们的零售企业只关注扩大获客渠道，也不是特别妥善的增收的办法。现在的获客成本逐年在增加，企业的获客能力却甚至在倒退，有质量的付费用户群体越来越容易被撬动，这对较传统的企业的冲击是非常强的。 举个具体的例子，比如；我就是一个网购爱好者，我喜欢在网上买东西，但也热爱去实体店体验试穿并购买。以前没有注意“线上和线下的体验”，但后面因线下有库存，线上没有的原因关注到了，我在天猫官方旗舰店铺是已经是V3会员了，但在线上的实体店里，我个人的属性仍然是普通用户。体验特别不好，‘至少我也是V3的会员啊’，怎么一点都不重视我呢？，所以就是哪怕实体店看好了，都不会在实体店下单，会优先考虑在天猫上同款下单~~~
产生这些消费观念的根本原因：
1.天猫有优惠券，买得多优惠的更多。
2.我也不差这么几天，什么时候寄到什么时候穿，时间不是痛点
3.确实和实体店的质量是一样一样的
图（二）
那么说到这里，那么问题&挑战来了！对于已经构建了自己的官方APP、官网的企业这也就会直接导致以下几个问题出来：
1.主站流量被“分割”
quj：客户不在企业官方通道下单，直接在天猫、京东以及苏宁下单。
2.应用去“中心化”严重，全渠道管理难上加难
Allen：企业自身维护的订单系统、分销系统、库存系统、物流配送系统多而管理成本高，再通俗一点，用户数据库就有好几个（比如自己官方一个、天猫一个）。这就是TO C/B其他电商渠道平台带来的平台“数据扭转割裂”的问题
3.管理成本“几何级”上升
Allen：第二点的补充，有部分传统行业是这样应对的。比如用户天猫上下单，确实使用了天猫平台的订单和库存还有会员系统，运行和表现都不错。但是我们的库存订单和物流中心的系统都是在线下，且独立运行的（又或者说是独立的团队支撑），所以这个时候就需要把天猫的订单重新在自己的系统里面再次录入一次。那么怎么解？这里“那就再顾个客服”做这个事情吧。
架构师旁白：
“2C平台到底自建还是用天猫？”
Allen：其实没有绝对的答案，在这个技术驱动业务的时代，本应该“业务数据流汇聚后，集百家之长。而并非绝对要一定选择一边，抛弃另外一侧”。
大致流程如下所示：（不严谨样例）
图（三）
所以，我个人认为，新零售它带来的除了技术的“革命”，还有更重要的侧重点是“打破数据割裂的格局”，在云端更好更快的处理，既而产生“数据价值”。解决“人、订单、物流(车)、库存、直营门店”的运行效率低下的问题。即“新零售”~~~
——包括微信端的终极“两个半”生态~~小程序：
图（四）
PS：不论是小程序上的来伊份也好，还是其他的华味亨等门店就更加典型，我也参与了来伊份2017下半年-2018上半年的信息化的建设，深有感触，找个时间也写篇心得给大家。
————————
这里推荐一偏运营的书《从互联网+从IT到DT》——阿里巴巴集团。
PS：讲的不错，有务虚也有务实。我虽然是2017年底开始看的，但是已经确认了拥有数据的公司，才能得以更好的生存的论点。
————————
好，不展开了，我们暂且先忽略提到的几个问题，
毕竟我们讨论的是Best Practice，在分析项目进展的过程中，大家要试着设身处地的思考。我分享的目的也是期望引发大家的思考，而不是告诉大家“以后”就这么做~~~~，毕竟有些说法还是比较局限个人且带有一定的主观意识。
这一次这个大企业所面临的业务问题就是天猫旗舰店的会员如何与自己的线下的旗舰店会员系统打通，所以这个就是前面我铺垫这么久的的总结~~~~~
“读者：“真的啰嗦啊，这人~~”：）”
天猫聚石塔官方是有成熟的解决方案——品牌会员中心，如下图所示：
图（五）
用户的收益：
为满足品牌对会员管理的个性化需求，基于会员中心全渠道会员打通的能力为品牌商实现会员注册、会员绑定、积分累计、会员互动、权益兑换等业务流程，并为品牌会员提供数据分析及精准营销的能力。
名词解释：
入驻天猫，需要“入塔”，什么意思？就是要入驻“聚石塔”，现在改名叫：阿里云-零售云。它与传统的阿里共有云（金融云、蚂蚁金融云）都在物理设施上有着完全物理隔离、数据隔离、网络隔离等区别。完全是独立的运营的，但也有一些联系！就是零售云本质上底层使用的就是目前阿里的公有云的那一套技术环境，所以在操作上并无特别大的区别。
补充说明：
当你经营着天猫的旗舰店，天猫（零售云）的数据是有非常严格的数据进出限制。基本可以理解为：“天猫的用户数据，阿里是绝对不允许你拿走的！”，这涉及相当多的数据安全和管控要求，大部分来自于国家的法律监管。
注释：关于零售云（阿里）平台的介绍不放在这一篇里面赘述，各位读者如果有心想去了解下，可以移步https://cloud.tmall.com。平台里面确实拥有大量的“零售业务”的阿里特质的中间件服务。适当了解下也不耽误多久时间~~~~
图（六）
好了，不再啰嗦了，上主菜！第一次项目拜访~~~~~~~【敲黑板，划重点划重点啦！！！】
第一次沟通是我们boss和公司cto直接驾车杀到客户总部，据后来了解是全英文沟通环境，虽然有客户的人兼着翻译一些疑问，但现场仍然多少有些尴尬~~~，客户由三波人（开发部门、业务部门、IAAS基础架构部门），我们则是boss和cto。一个二十人的会议室坐的满满的。是个大场面~~~~~
Topic-1，项目背景、项目POC测试情况、天猫-JST平台的情况（这里指的是客户对平台的熟悉程度）
Topic-2，我们公司能给予的全栈支持汇报、公司目前的资质情况、技术人员的构成情况、云服务的详细清单和服务边界、以及是否有服务的类似项目案例
Topic-3，交流话题三，项目启动和交付时间。
Topic-4，交流话题四，整个项目背后实现的业务设计和调用逻辑（偏开发环节）
架构师事后思考旁白：
这一次拜访不同的是以往都是只有一个部门参与，这次客户集中了三个部门参与。我们在这个拜访过程中集中聊了业务的实现流程。可能跟CTO在场的关系，所以聊了比较多业务运行的。因为个人行程问题会议没参加，故我简单的总结下。客户对我们的感知除了基础云运维服务、业务的理解能力，还有我们的基于云平台的专业能力。
~鉴于我们对“零售云”平台并没有特别的客户案例背景，所以有相当多的技术问题需要了解和学习。所以这个时候我们找到了Partner去一起参与项目，但后面因为Partner的时间安排不过来，后面就决定还是自己来了。但是非常感谢Partner的前期交流和支持！~
同时也意识到自己需要更多的测试来验证自己“天马行空”的架构设想，所以同步找了公司申请一部分的资金来进行平台部分特×××的测试费用。
——————————————————————————————————————————————————————
做任何事情，不要忽略你或可能得到的公司的支持
——————来自于Allen
——————————————————————————————————————————————————————
协商完成后，用自己的支付宝注册了账号，尝试开些机器学习docker开通和交付以及平台相关特性。这里我也贴一些熟悉平台过程中的一些经历“截图”，平台截图如下：
图（七）
适应过程中，我也邀请了我们的售后团队参与其中，大家适应的效率非常高。最后确认了好几次后给出“和公有云部署基本一样”的结论。
这列几个里详细区别——————————
1.没有安全组的设置界面，因为“零售云”对于有着严格端口控制，平台内部已经做了严格控制，如果你的业务是非默认端口，或者需要使用其他的端口，就需要申请了。如下所示
图（八）
?PS：聚石塔主机默认开通30001~30005端口提供使用，如果需要额外的端口需要提交端口开放申请。??
2.默认给计算资源（ECS）提供2GB的DDOS×××防御，与“公有云的5GB防御”略有不同
3.可以部署自建的监控工具
4.有很多场景化的PAAS产品，这很“零售云”，例如：御膳房、数据银行、电子发票、阿里全渠道服务、会员运营平台短信服务、顽兔多媒体等等
5.额外提供了一个类似传统组网中DMZ区域的功能，但比DMZ区域强很多。即：御城河
6.最后就是本次项目中最核心的Docker服务—EWS?
1）这里我们把EWS的服务展开稍微带一下，如下截图所示：
图（九）
图（十）
2）这个容器(EWS)有一点不同，在提供统一容器管理和运维平台的时候，他同时也提供了基于EWS的统一接入管理层，如下图所示：
图（十一）
3）从以上图上可以看到，EWS在IAAS这一层上面做了一层控制层面的服务，ECS主机购买完成后，进行agent的安装，容器即添加完成。所以我们在平台上的设置时也证明这一点（如下图操作说明所示）：
图（十二）
4）我们再详细看下EWS起某一个服务时候的配置界面：
图（十三）
当我们使用了统一接入层，我们就无需额外购买【外网负载均衡】，相当于平台提供了免费的负载均衡给你使用。当然也可以去接，只是有些业务不适合接外网的SLB，所以分析好业务需求很重要。默认一般使用EWS提供的LB
5）最后完成基础的创建后，我们就可以看到控制台看到这样一个界面：
图（十四）
6）点击容器管理，进去就看到运行的容器了，就可以欢快的运行自己的业务了：（容器内部有对应的版本管理等一系列标准的功能模块）
图（十五）
回神过来，差不多一个礼拜，内部团队彻底消化这个从零到一的过程，挑战是有的，但很享受。
紧接接着回到项目中来，第二次沟通，我又因为时间冲突没有前往客户现场进行沟通，（我这售前确实有点不称职~~~）
Topic：
1.架构类似业务实现案例分享
2.项目预启动
3.团队人员角色互相认识
架构师旁白：
所以说，第二次会议是很重要的（几乎可以与世界杯临门一脚相提并论），因为客户关系、商务问题都经过了老板亲自带队搞定的，结果项目启动时候，我这个架构师（项目经理）又不在。现在回想起来，着实有点让我挺抱歉的。
~~~~好，现在开始了本章最最最最最最最核心的部分——“方案、报价”
【读者：“我了个擦，这兄弟咋这么唠叨~~~~”】
一、方案怎么写？（Solution）
二、报价怎么弄？（Cost-Effective）
三、实施文档怎么搞？（Sop）
四、项目流程怎么管？（PM）
五、信息安全（Security）
六、灾备预案
七、~~~
一大堆的问题，老板丢给了我，现在想想当时自己的心态，着实有点“强”。是不是有这种“遇强则强”的能力呢？其实我也不知，emmm~~。总之那两个礼拜几乎天天到夜里十二点，是非常正常的事情。也有几次熬夜经历!!
“待我一一详细分解给大家”讲讲！
1）第一期技术方案框架：
核心需求：国内到国际延时优化、Docker（EWS）、Proxy反向代理
基础架构业务流梳理：
Tmall————JST————Aliyun-Cloud（China）————Aliyun-Cloud（Global）————AWS（US）
1.1）第一期技术报价明细：
IASS资源：
Aliyun-Cloud(China)：24W
Aliyun-Cloud(Global)：12.4W
JST：21.1W
Total：57.5W
云服务：147W
1.2）第一期方案报价Total：204.5W
1.3）第一期方案三年Total：601.5W
架构师旁白：
? 为什么服务费会有这么多？达到1:3，请留意一点，外企用户真的是非常认可服务提供商。而且所有的每一个环节的工作内容都需要被颗粒度到非常细节，并需要SLA保证、SOW的文件支持。所以外企做事情严谨（效率慢是有道理的）的工作态度，着实值得我个人学习。
在进行第一期技术方案&报价方案交流过程中，我和老板也同时处理了关于《Vendor Service Questions》的问卷调查，因为是第一次处理这样的文件，所以多少是有点经验不足和一点小兴奋（全英文环境），被打回两次后，终于通过了客户的要求！！
我截部分脱敏问答给大家分享下。
图（十六）
回到技术方案上，第一期如我和老板所料，被打回了。技术细节要调整。原因是：基础资源架构过于多余和服务昂贵。希望将国内阿里云、国外阿里云删减，并剔除部分服务内容。
图（十七）
花了一天时间，技术框架和报价方案调整完毕，第二期技术方案框架：
核心技术匹配：Docker、Proxy反向代理
基础架构业务流梳理：
Tmall————JST————AWS（US）
2）第二期技术报价明细：
IASS资源：
JST：21.1W
云服务：41W
2.1）第二期方案报价总计：62.1W
2.2）第二期方案三年总计：174.3W
注意~！！！方案调整明细如下：
第二次与客户负责人沟通交流，客户部分工程师再次认为有部分安全资源是多余。
Why？因为整体的业务的触发来自于Tmall的平台，JST本身业务不直接对外且点击跳转的流量全程已经是“加密”“合规”的流量，如果中间再加了安全层“检测”，未知潜在的问题会有很多，客户希望尽量避免增加额外开销。
第二次删减内容：Waf、态势感知、服务器数量缩减
经过一天调整后，我们随即再次约到客户进行第三期交流资源配备方案：
第三期沟通后，业务流程如下：
Tmall————JST————AWS（US）
3）第二期技术报价明细：
IASS资源：
JST：5.6W
云服务：25W
3.1）第二期方案报价总计：30.6W
3.2）第二期方案三年总计：91.8W
———————————————显然“事不过三”是有道理的，果然到第三期方案的确认，我们达成了共识，并确认技术方案没有其他问题，
整理下这个“一上一下”的落差的过程：
1、第一期方案，我们给出的是最大最理想的方案推荐
2、第二期方案，我们给出了一个合适体量且理想的方案推荐
3、第三期方案，我们给出了最小化上线的方案
注释：
从600W到91.8W这个降幅确实大，但客户说的总归是没错的，所以客户既然这么要求，那作为售前也好、销售也好，满足他，让客户感觉到爽舒服即可。
差不多的进行到这里的时候，客户公司的第四个部门（信息安全）找到我们（前面是基础架构、法务、商务），要求审计我们的信息安全&合规性等情况，第二次审计工作的暴风雨来临了~~
PS：还是一样，我share部分脱敏后的内容。本文旨在分享经验，而不是详细的材料和文档。请各位读者留意，切勿私信找我索要相关文档，因为前面几次的分享出现过很多次这样索要的情况了，很显然这些文档我不能Share的。
1.Have company information security policies been published, approved, communicated and reviewed in the last 12 months?
2.Are passwords for systems containing scoped data hashed or encrypted in storage to protect from unauthorized disclosure?
3.Has the security incident response plan been tested in the last 12 months?
我大概“撸”了一遍后，总结下来问的问题比较通用，我能从文档提交的内容中看出，客户对所有类似我们这类MSP云计算服务提供商都有一套这样的流程去管控，故，我非常放松的去做了这个事情。总计调查130项，每项都需要详细的文档支持。不能简单的回答“yes or no”
这个调查，我看了间接花了我大概12天的时间。最后比较波折的通过了。本来以为结束了，开始部署实施了~~~
结果客户的基础架构架构部门再次找到我们，要我们给客户提供的《XXX-项目零售云平台规划》重新以客户的文档管理结构进行修正，
这是我们提供的文档部分截图如（已和谐）下：
图（十八）
图（十九）
这是客户提供的文档部分格式（已重度和谐）下：
图（二十）
图（二十一）
注释：得到这个消息，我其实是拒绝的。。全新的文档格式、方法论、排版。这一part，我直接跳过过程，总共开销花了5天左右（当然是和其他工作同步进行的）
好了，还有实施进展中的一些技术攻坚，我放到下一次详细分享，这里对今天以上内容总结下架构师在这个项目的核心能力需求：
1.对业务的工作流的了解
2.云平台的实施部署经验、特性和安全合规的理解
3.丰富的文档（表格）制作功底
4.有足够的耐心讲业务实现细节阐述清楚，并形成文档
与甲方用户通过skype开会汇总：
1.技术架构细节：3次（≥60min）
2.堡垒机的使用和灾备方案：2次（≥90min）
3.JST资源配置方案：8次（≥60min）
4.JST资源付款形式：2次（≥30min）
5.信息安全细节：4次（≥60min）
6.JST资源购买方式&付费开通：3次（≥120min）
PS:这些会议都是穿插在整个项目中的，全部由boss、我和我们服务团队共同完成的。
最后补充几个平台监控的知识点：
1. EWS容器的扩容，只要计算资源（ECS）足够，则可以通过任何ECS去添加到容器中运行，建议启用EWS-LB服务，横向平行添加即可，保证配置文件、版本一致即可。
2.监控对于用户来讲，可能更关心PV、UV等数字。对于运维来讲可能更关心服务运行、ECS的机器运行情况，已经容量等问题。所以运维相对简单（zabbix+wechat）对接即可。或者有自有的其他监控均可，保证响应时效即可。
业务的监控，JST平台已经内置好了，如下图所示：
一个热爱生活的网工努力的故事
——————Allen在路上
QQ:549675970
Wechat：
Johnny_JunJun
QZONE:
http://user.qzone.qq.com/549675970
E-mail：
[email protected]
[email protected]
人生格言：越努力、越幸运
原文地址：http://blog.51cto.com/allen686/2133440