问题提出
本日在电商金融架构群里，来自蚂蚁金服的于总抛出了一个问题：“完备从0到1培植一个电商网站，技能上如何选型，如何快速上线？”
群友们群策群力
参与谈论的电商公司背景：有来自传统行业的“互联网+”式的电商平台，有目前正处在风口的“跨境电商”，也有来自有名大公司的电商实践等。
UC的莫俊彬说：
我以为...先把根本举动步伐弄好，上云..搞业务..这样精力就集中了”（给赞，还卖了一手好萌）。
北京的isnow分享了他的经历：
“我们是去年10月份(注：2014年)从0到1搭建的电商网站，做知识产权电商，2b2c的业务，开始在都城在线的云上，前端是用bootstrap，利用nginx做负载均衡，后端用springmvc+spring+mybatis数据库用mysql，支付接入第三方支付，支付宝和银联支付，网站分前端用户访问和后端业务系统，分开支配，前端支配在两台tomcat上，mysql一主一备，这大概是我们的初版系统的架构。开始的时候产品线比较单一，将主打的产品上线，然后在后期迭代过程中逐步上线其他业务。”
于总心想我才不相信你们没碰着问题，说问题。
然后isnow就开始倒苦水模式:
由于职员和流程的问题，每次上线都是直接将变动的class文件支配上去，代码管理没跟上；
随着业务线的增多，创造最开始的业务架构无法扩展，每次增加业务线代码重用效率不高；
由于业务线中存在大量的文件，导致随着订单的逐渐增多，文件io变慢 ；
随着业余订单的变多，订单访问开始变慢；
由于业务系统是o2o的模式，客户那边做业务的时候随意马虎对业务常常状态变动，现阶段都是专人在数据库上变动数据状态，个人以为太危险；
业务方变动太大，我们的产品暂时在市场上没有可借鉴的(第一个吃螃蟹的)，因此在业务上一贯都是在变动，然后就形成了一种业务混乱的觉得。后来，招了cto，改第二版时候把大量的业务逻辑转移到数据库里用存储过程来办理，导致业务逻辑分散。
觉得创业公司实在技能过得挺困难的，招不到好的职员，领导在新技能的考试测验上每每步伐没那么大，不敢轻易上他没有把握的技能，有时候乃至为了稳定去姑息一些技能乃至业务上的坑”。
于总看到这里瞬间不淡定了：“CTO的履历决定技能堆栈啊！
存储过程是一个大坑，未来要分离，做事，可读性都是问题”。
小刚插了一句：“硬件和网络，直接买厂商的”(土豪任性)
来自金山的Kerwin说：“先想一个能扩展的框架”（果真是大公司的，家底便是厚呀）
北京的孔庆龙则说：完备从0到1 培植一个电商网站？
如何选型，首先要清楚自己想要什么这个就要做好业务剖析和业务架构和计策整理，进而找到关键需求，通过关键需求来对市情上的技能或者套装软件进行选型——也便是运用架构选型。
快速上线：这个涉及到的问题较多，如数据架构、根本架构、运用架构、安全架构等一系列问题，如果安全架构不高那么上云是一个不错的选择，毕竟云可以供应一整套的PASS和SAAS办理方案。
关于技能栈：紧张是根据自己的团队职员量身打造，从前到后有前端技能选型（jquery、Bootstrap等）、HTTP网关或LBS（nginx、F5等）、容器中间件（Tomcat、jboss、weblogic等）、运用（SSH、分布式的dubbo等）、数据库（mysql、redis、oracle、db2等），监控软件（运用监控、网络监控、数据库监控、做事监控等）
关于团队：如何快速构建如何上实现DEVOPS（技能工具如：maven、svn/git、sonar、jenkins、Confluence、jira、nexus等）
于总补充到：“容器中间件（Tomcat、jboss、weblogic等），现在都是tomcat 和jetty，其他的太重。”
刚开始做跨境电商的Jesse说：项目一个半月上线。
做事器与数据库直接买现成的，减少运维本钱。目前我们是ECS加RDS，全是阿里云。 框架是Spring+Mybatis，做事器是tomcat
图片存储用的是OSS，自定义域名，CDN加速（也是阿里云的）首页优化包括动静分离，异步加载，用户首页打开速率从7秒多缩短到了3秒以内。 由于上线匆忙，很多细节来不及优化和确定。以是对付一些常常变动的模块直接用新的工程。这样要修正不会影响到其他模块。 代码管理用Git。没有service话，觉得用不到。
缓存直接是EHCache，每个机器都保存一份。没有用memcache，由于目前memcahche还是会增加管理本钱。
负载均衡也是直接上阿里云的负载均衡
快速上线的一个问题便是好多技能设计的细节没有考虑完善，代码比较粗糙，但是又不能做大的调度，而且还要兼顾新的功能。目前的做法是，业务须要变动哪一个模块，就去在做业务的过程中去重构，而且做灰度发布。
业务上跨境电商的一个最大问题便是货币问题。不同国家的用户登录显示的货币要不一样。对付产品，报关是个大问题，现在这一块都是运营手动报关发货。现在还做不出来那种跨境DRP，纵然购买现成的做事也不知道该咋用。 汇率是采取一个月取均匀值。要判断是哪个国家的话。。先做成让用户自己选。。但实在现在便是中文和英文
UC的莫俊彬接着问了一个问题：“初期数据支撑，这块觉得不好做，不知道有没专做这块做事的公司。”
来自北京的俞斌说：“我们全部阿里云。”
来自深圳的小刚说： 我们的业务才刚起步，技能上没有太多的创新。
硬件带宽：非核心业务，阿里云；
整体架构：分层模式+微做事模式，可复用的核心功能下沉、抽成做事。
技能选型
3.1. 网站前端php+yii+thrift+阿里ocs+mysql；
3.2. 后台做事spring+mybatis+thrift+dubbo+mysql
末了来自友群的朋友分享了他们的履历：
我们现在电商平台，算是从0-1，我全程参与过，技能选型也都参与谈论过，现在来看的话，犯过以下几个缺点：
没有准确估计实际业务量或是就没估计，导致技能选型直接参考京东，淘宝等一线公司，实现较繁芜，技能铺的也很大。
由于短缺履历的缘故原由吧，前期业务没有明确的方案，技能选型也没有考虑高内聚，低耦合，导致系统之间依赖太强，现在想拆分很难
选择了一些较新的技能框架，依赖于1~2个技能牛人，牛人离职，一片茫然。。。
初期除了购买流程上不能有技能短板外，产品为核心的营销数据流也很主要。提升流量，用流量测试转化率和动销率，然后想办法提升这两点。一旦转化率稳定，才是买大流量的时候。这些都要有数据支撑试错。
总结
末了我们总结了一下我们的谈论：
快速上线，知足目标不要做过多设计，大概用到的技能堆栈有：
电商平台一样平常都分为面向客户的客户端网站系统、面向公司内(或第三方平台)的业务系统以及运维平台(云平台)。
对付面向客户真个网站系统紧张包括以下几个模块：
1. 用户管理系统
2. 商品管理系统
3. 支付系统
4. 订单管理系统
5. 评价系统
对付面向公司内(或第三方平台)的业务系统紧张包括以下几个模块：
职员管理以及权限管理系统
客户做事系统
订单管理系统
财务管理系统
商品掩护系统
数据统计系统
运营支撑系统
紧张架构图：
从图中我们可以很清晰的看到大概的技能栈：
1. 前端系统:
1.1 Web端技能选择:
1.1.1 JS框架搭建
1.1.2 PHP框架搭建
1.1.3 JSP/Freemarker模板+UI框架(Bootstrap等)+Jquery工具
1.2 移动端
1.2.1 Android平台
1.2.2 IOS平台
1.2.3 Mobile(H5)平台
2. 后端系统
2.1 负载均衡系统
2.1.1 硬件类负载均衡器
(1). NetScaler
(2). F5
(3). Radware
(4). Array
2.1.2 基于Linux免费开源的负载均衡软件策略
(1). Nginx
(2). LVS/HAProxy
(3). Lighttpd、Apache-mod_proxy、Squid、Socks、TIS FWTK、Delegate等
2.2 web容器集群(最根本的集群，一主一备)
2.2.1 传统模式，将所有模块定义到同一个项目中发布到web容器中
2.2.2 SOA模式(微做事模式),根据业务模块将系统进行拆分，分开支配，系统间利用rpc或rest办法调用。详细可参考dubbo(dubbox)、Spring-boot等框架。
2.3 文件做事器
2.3.1 储存办法
2.3.2 储存容量
2.3.3 安全性与存取权限控管
2.3.4 存取效能
2.4 缓存做事器
2.4.1 分布式Redis缓存
2.4.2 Memcache缓存
2.4.3 EHCache等
2.5 系统
2.5.1 ActiveMQ
2.5.2 分布式系统Kafka、Rocketmq等
2.6 数据持久层
2.6.1 关系型数据库
(1). PostgreSQL
(2). Mysql
(3). Oracle、DB2等
2.6.2 Nosql
(1). MongoDB
(2). HBase等
注：硬件办理方案的优点是：有专业的掩护团队来对这些做事进行掩护、缺陷便是花销太大。软件办理方案的优点是用度低廉，缺陷是开源系统，可能出问题得自己想办法找办理方案。
CTO(技能卖力人)会很大程度上影响技能发展
CTO 在创业公司扮演了的角色很独特，创业公司CTO不仅卖力业务上的开拓任务，还卖力扛住外界(其他部门卖力人)的压力等。对内还要卖力团队职员的合理搭配和安排，对外卖力开拓任务的安排和调控。 同时CTO在技能选型上更多时候考虑的是自身熟习的技能以及稳定的技能，或许创业公司有更多的试错机会，但毕竟是身处创业的环境，外界环境不可能给予团队多次失落误的机会， 因此在技能选型上包括公司技能走向上更多的取决于CTO对技能的闇练程度。
发展过程中碰着的问题
问题：
1.由于创业公司迭代非常频繁，因此运维上线的问题是最大一个很大的问题
我们开始的办理是每次将修正后的class文件直接更换线上环境，这种方案是非常危险的。后期我们搭建了自动支配平台，基于Git和Jenkins进行代码自动化支配。
2.前期由于各种各样的缘故原由导致业务逻辑上耦合程度高，开拓新业务线的本钱很高
这个没办法，前面挖的坑后面逐步填，然后在重构的时候，一点点的将业务独立出来，利用微做事办法进行架构。
3.前期未将系统中文件同代码分离出来，导致随着用户量增多，做事器IO越来越慢
搭建文件做事器，将所有文件移到文件做事器中，减轻web运用做事器的压力。
4.随着订单的增多，后台业务系统订单访问变慢
第一步，从sql优化的角度，看是否能够通过加索引等办法加快速率。第二步，打算订单干系表的读写比，进行分库分表操作。(目前我们团队还未到达这一步)
5.业务方需求变动太快或产品思路不清晰，每次迭代都是在挖坑
这个没办法，第一，探求更加懂业务的产品经理。第二，业务开会须有核心业务开拓职员参与，对需求或产品的发展做出中肯的评审
我们的关于从0到1的电商平台培植的一些建议
对核心业务思路要成熟，不要人云亦云，千万不要说\"大众淘宝、京东便是这么搞的\"大众。要结合自己的产品和业务去架构自己的平台。
在技能选择上，只管即便选择开源稳定的方案，不要选特殊新的技能。
前期可以将非核心数据或做事托管在稳定可靠的云做事平台上，集中精力将核心业务完成核心业务的开拓和产品迭代，到团队有一定的积累后，可选择自主开拓某些托管在云平台的做事。
能选择将业务分离开，则只管即便分离开，以方便后期产品的重构。
