相关规定是：经营性网站需要向通信管理局申请ICP证，非经营性网站只需要作ICP备案即可。而同时还有一条规定：申请ICP证需要企业的注册资本达到100万RMB。这就有个问题：如果是100万注册资本以下的经营性网站是否需要ICP证，是否能申请到？
而好像目前国家对这一块的监管是很松的，除了几大B2C和C2C网站（当当、红孩子、京东、淘宝等），基本上所有的B2C网站都只是做了个ICP备案而已。
请问各位B2C的老大们，现在不申请ICP证，是因为注册资本不到呢，还是因为现在国家不管这个？
应该要吧，知道细节的派友们帮忙回答下阿，呵呵
个人是人为 ：这种事情最好是能和相关部门沟通清楚，一但出问题，这些人可不好说话
我发现Vancl也只是挂了个ICP备案。
可能是查得不严，但是，这种事情跟撞大运一样。
我的风格就是，能办就赶紧先办了。
有ICP证才能办红盾，有了ICP证和红盾，你可以宣传自己正规，没有的都不正规。
很多B2C没有ICP证的原因：1.大部分B2C注册资金不到100W，2.ICP证办起来比较麻烦，时间长不说，还需要准备一大堆材料，来回来去折腾好几回，当然，不想自己麻烦可以找代办公司，几千块钱。
目前办理ICP证需要注册资金达到100W以上，给中介公司2500全部搞定。
(注：名义上外资、中外合资企业可以办，其实是办不下来的。广州的朋友建议不要用厦门的服务器，具体说明原因就不清楚了。)
我也比较关心这个问题。已经搜索了相关信息，好象是有不同解释。
所谓经营性ICP，是指网站的内容本身就是经营的对象，比如提供收费信息、有偿新闻，阅读这些信息本身是要收费或者可能要收费的。
而B2C网站不存在阅读信息收费的问题，也就是说，经营的是产品，而不是网站的内容（即：不是通过“互联网向上网用户有偿提供信息”来获得）。因此不需要办理ICP证，只要和营业执照上的经营范围一致即可。
参考信息如下：
通过电子邮件服务、通过电子支付的网站是不是经营性网站？
根据该文中上海市通信管理局的答复，以及杨宝春律师的回复，B2C网站不必办理经营性ICP备案，因为判断的标准是：浏览信息是收费的还是免费的。经营性ICP备案管理办法中的“电子商务”一般不应包括通过网站展示产品信息促使用户完成线下交易的行为，线上支付并不能改变“线下交易商品”的本质。
感谢楼上各位连夜解答。
这个问题，我也打过电话给北京市通信管理局的市场监管处（），对方的答复跟冰寒了解的情况一样，对于B2C或电子商务这种模式的网站，不需要申请ICP证。通管局对电子商务这种不是提供“有偿信息”的网站，其意见是不需要申请ICP证的。
在网上查看了B2C和C2C网站，发现大部分都申请了ICP证（淘宝、易趣、当当、卓越、京东、红孩子、梦露时尚、七彩谷、携程、e龙），而只有ICP备案的网站有：北斗、Vancl、ppg、云网、新蛋等。
既然通管局是ICP的主管机构，他们的答复应该是权威性的，何况还有律师也是这样认为的。对于较大的电商网站申请ICP证的原因，是不是可以这样认为：为了以后的监管风险考虑，万一政策变了再去申请怕来不及；或者是为了日后商业模式的一些变化，以防自己需要提供一些有偿信息服务。如果注册资本的条件满足了，去办一个ICP证还是有备无患的。
学到东西了，谢谢分享啊！小心驶得万年船
我也一直在考虑这个问题，怕有天一旦查起来，网站不能经营，就麻烦了，我的想法是国家开始不会对电子商务控制太死，这样会影响到这个产业的发展，一般的规则是先发展，后规范，所以我想肯定会有规范的那一天，所以我们也想如果不麻烦，尽快办理ICP证，但是国家政府部门的效率和态度的确是，他们是老大啊，什么时候他们的服务也像招行，SONY ,HP这些企业的服务态度和服务效率，那中国的发展就会更快了。
办ICP证，没有那么麻烦的，我N年前亲自办过去2趟就全部办完拿照了，我个人意见也是应该办一下，不知道政策什么时候就变了。
我以前也对此了解过，但各地对这个解释又不同，现在只能等网站一切顺利后再去申请&
恩 ，这个问题也一直困惑，现在终于清楚了，呵呵
这个，我只能说最好是把ICP证办了，有条件把SP证一起办了。钱也花不多少，但以后的用处却很大。
学习了，这个。～
这个我也早了解过，船大了，还是找个专门法律顾问比较好：）
这个我也了解过，但船大了，还是找个专门法律顾问比较好：）
能办的话就去办了
办一个没有坏处～
好文章，收藏
回复：4 楼 @ 星星
请问,为什么不要用厦门的服务器啊,说下原因,了解下,
参考信息如下：
通过电子邮件服务、通过电子支付的网站是不是经营性网站？
根据该文中上海市通信管理局的答复，以及杨宝春律师的回复，B2C网站不必办理经营性ICP备案，因为判断的标准是：浏览信息是收费的还是免费的。经营性ICP备案管理办法中的“电子商务”一般不应包括通过网站展示产品信息促使用户完成线下交易的行为，线上支付并不能改变“线下交易商品”的本质。
呵呵，应该是杨春宝律师，电子商务专业律师。其实不能简单地说B2C网站是否是经营性网站，而是要看是否“有偿提供信息”，是需经许可，否只需备案。不过现在备案也很复杂了。请参考：
互联网信息服务管理办法
更多有关电子商务法律信息，请访问法律桥（）
学习了，这个证确实麻烦，特别是有论坛。
学习了，这个证确实麻烦，特别是有论坛。
经营性ICP证注册资金100W，不办好像也无所谓吧
先来一个备案的~
电子商务网站目前是不需要ICP证的，但楼上有兄弟说要办红盾必须要有ICP证，所以有可能还是去办个ICP证吧。ICP证我前后办过7、8个，有北京的，也有上海的，就是弄个商业计划书，再填些表格基本就会申请下来，商业计划书不要写你的电子商务的东西，忽悠个信息收费的服务，随便写，反正那些人也不会去网站上查的。另外注册一个100W的公司不一定非要资金全部到位的，现在还是有些地方可以帮你垫资注册的。
引用 (wdjtony @ 08-09-08 15:56)电子商务网站目前是不需要ICP证的，但楼上有兄弟说要办红盾必须要有ICP证，所以有可能还是去办个ICP证吧。ICP证我前后办过7、8个，有北京的，也有上海的，就是弄个商业计划书，再填些表格基本就会申请下来，商业计划书不要写你的电子商务的东西，忽悠个信息收费的服务，随便写，反正那些人也不会去网站上查的。另外注册一个100W的公司不一定非要资金全部到位的，现在还是有些地方可以帮你垫资注册的。感谢tony，提供的信息很有用，也很实用。
一般做的不大,国家也不会去"关心"到你
除非你做大了.还是没有办ICP证
那就"枪打出头鸟".你就倒霉了!
做大了在说!
回复：6 楼 @ 罗迪克
哇迪克兄，你知道我找那个信息是多么费力吗？挖google和百度的页面，我换了几十个关键词，翻了几百页才找到那个链接中的文章。
现在得到你的证实，真高兴：）
关于ICP备案，再问一句：
什么时候可以开始进行备案？在域名可以访问时就可以开始进行吗（即使此时网站仍处于测试阶段）？或者说，我提供几个跟实际运营时内容一致的测试网页，供通信管理局访问域名时核实内容，这样的做法行吗？否则的话，如果等到网站公测时才进行备案，在得到答复之前就没有ICP备案号，这段空白期能进行B2C的运营吗？
有ICP证，他们就可以经营网站上的广告等内容。搞b2c的，都是商品，与广告不相关。所以不需要。
回复：33 楼 @ 回龙观购物网
经营网站广告，好像需要“广告经营许可”吧？有谁清楚这个？
呵呵，公司有实力就半个ICP证。
小电商就申请个ICP备挂挂。
办这个证好麻烦，我们公司办这个证前前后后花了一个多月的时间才搞定。
如果大家想做大的话，建议办理icp证
过程不是很复杂，也不是很麻烦，我们是新的企业，一个新的B2C，办理这个证件只用了1周多一点的时间就下来了。当然了是走了一些关系，如果不走关系大概需要1~2个月的时间
需要提交的证件和资料也不是很烦琐，准备这些东西大概只用了2天时间。
如果大家想问下需要办理什么证件和资料的话，可以加我QQ，我可以提供给大家相关的资料
另外我想说为什么要办理ICP证，如果想做大的话，就一定要办理这个ICP证，可以说，我们现在做的这个根本不需要ICP证，在ICP经营范围中，没有任何一项跟我们有关系，最后的项目选在了，互联网信息服务，而按照里边的相关条款和说明，这个是向用户收费的，我们B2C只提供产品的免费信息，根本不涉及到收费情况。所以不用考虑。
如果大家办过和银行合作，或者是办理一些红盾，还有公安等后续很多东西后就会发现。现在我们和8家银行谈合作，其中7家银行需要ICP证，公安那里也需要这个东西，其实这个就是一个通行证，是证明你公司实力还有一些别的东西用的。所以为了以后长期很好的发展建议把这个东西办下来。
很不错，收藏
能办最好提前就办了& 免得夜长梦多
ICP证~~现在大部分B2C网站都没有100万的注册资金，怎么办啊？有哪些公司可以代办？
这个问题困惑我很久了,终于在这里找到答案了
肯定是要办的，而且是免费的，也相当的容易，你在湖北的话，我还可以有偿帮你整理申报资料。
单独发了贴，被斑竹删了，这里的信息解释了我一半的问题，还有一个问题是网站的论坛是否需要办理BBS专项审批！可能大家都没注意到这一点。
已经办了，最怕政府来麻烦我了，我不善于和那些满口假话的官应酬。
好贴,透彻.受用.
对于创业者来说，可免则免。在国内，只要能做大，没有东西以后是办不成的。
这个嘛,怎么说呢?目前来说国内的电子商务是有点混乱,但也正在走向规范!办证经营那是迟早的事!
不过在某些方面目前来说对中国的电子商务发展会有阻碍!很多公司都是从小走向强大的!目前很多经营不错的B2C都是比较有潜力的小公司!眼实是达不到要求!现在如果强制性的办证!那不又扼杀了一群网络精英!
其实这个标题应该改一下，变成“B2C电商网站是否需要经营性ICP备案”
直接去办,很方便的.
我的一概宗旨是：能学就学，能办就办；不追求现在的回报，就看望将来的成果。
@你关注的人或派友
亲，先登录哦！
请输入姓名：
请输入对方邮件地址：
您的反馈对我们至关重要！您的位置： >
DIY首页2014
CPU内存硬盘排行榜
DIY热门文章
CPU内存硬盘> 博客详情
文章来自 在外企和互联网碰撞的猴子 的微信公共账号。是我们跨境电商项目的架构师写的。我们项目的每个点读提到了，方便记录查找，我转载一下。
针对如火如荼的跨境电商行业，催生了提供一个SaaS电商平台为一些传统企业和机构开展跨境电商业务的市场机会，所以我们有机会来做这件事情。今天重点讨论销售和运营系统，不涉及跨境贸易价值链中的采购、通关、购汇结汇以及支撑电商业务的CRM，OMS，ERP等系统。
团队成员-最初由3名具有比较丰富企业级电商平台开发经验（&6年）的资深工程师组成，经过1年发展，团队规模成长到30+工程师。
1.&领域驱动&– 基于自己对企业级电商平台设计和开发的丰富经验，进行领域建模，并将领域映射到业务子系统，划分高阶系统边界
2.&分布式、服务化&- 吸取企业级电商平台的经验教训，各业务子系统独立开发、测试和部署，子系统以服务暴露自己的能力，子系统与子系统之间以服务进行通信和交互。这一点可能会有些争议，在业务发展初期，整个系统的容量不需要那么大，分布式是不是设计过度，特别是在部署上对一个小团队来讲也很难驾驭。在项目中途我也曾经深深的质疑过这一点，但是慢慢也体会到它带来的好处，放开分布式架构带来的未来系统更容易更灵活的优势暂且不谈，至少每个业务子系统能比较独立高效的开发，测试和部署，在一个高速发展的团队，不可避免的沟通会成为一个巨大的挑战，这种独立性可以很大程度减少一些艰难和低效的沟通。
3.&持续集成&– 从第一天开始建立持续集成的体系和流程，保持开发、测试、部署的高效性
第一阶段（2个月）
在人员有限的情况下，以一个业务领域切入，构建业务子系统，确定基础技术选型，提供业务子系统的样本项目工程和框架供后续业务子系统开发参考。因为交易是电商平台最重要的一个业务领域，并且涉及到跟几乎所有其他业务领域的交互，我们选择交易子系统为切入点。
基础技术选型：Java+Spring作为服务开发的基础框架，MySQL存储交易数据，RestEasy作为REST服务框架，子系统间的服务调用使用Hessian。因为团队成员曾经在淘宝交易平台的工作经历，整个服务框架基础技术栈的的选型深受阿里的影响。
1. 一个业务子系统由-app, -client, -server三个项目组成。其中app是controller层，通过RestEasy把服务以REST接口发布出去；client暴露了业务服务接口及Domain对象；server提供业务服务的实现。这里app不会直接调用server，app需要调用业务服务也是以client为入口。这里主要的考虑是基础服务和应用服务这两级服务的概念。这个概念相信了解淘系系统的人不会陌生，基础服务只提供对核心领域对象的基本操作（典型的增删改查及基于此的一些基本操作），应用服务一般对应一个业务场景，需要调用一个或多个基础服务，进行串联、聚合或其它计算处理。例如：购物车的增删改查是典型的基础服务，而计算购物车时一个典型的应用服务。这样设计，随着业务量的增长，系统未来更容易向微服务架构演进。
2. 业务子系统打包成WAR部署到Tomcat需要一个web项目，-web，Web项目里，包含datasource，hessian服务发布，声明包含哪些业务子系统，以及配置文件。因为在项目初期我们需要支撑的业务量还没达到一定的规模，出于成本控制的考虑我们需要将多个业务子系统打包发布到一个WAR中，所以这里出现了需要在Web项目中声明包含哪些业务子系统。未来如果需要从一个WAR中将一些业务子系统拆出来单独发布，也比较灵活。
3. 服务调用框架，说到这里，大家第一反应肯定是Dubbo，在项目初期，我们并未使用Dubbo的方案，主要是考虑到团队成员并没有Dubbo使用的经验，而且在我们并未产生大规模分布式服务和服务治理的需求时，Dubbo的使用在项目初期反而可能成为我们的不可承受之重，把Dubbo用起来并不难，难的是如何驾驭它。所以我们选择使用DNS+Load Balance来做服务发现，基于动态代理实现了Hessian/Local/Mock的服务调用机制（Local主要用于不同业务子系统部署到一个WAR中，Mock主要用于UT），每个Web项目提供一个服务调用的配置文件，配置这个Web项目要调用的服务的调用机制和服务endpoint，因为我们使用DNS+Load Balance来做服务发现，所以服务endpoint都是Load Balance的地址。
4. 分布式日志，分布式服务调用如何跟踪一个请求的整个服务调用链条，是我们必须要解决的问题，基于Google的Dapper论文，淘宝实现了EagleEye。其实Dapper的原理并不难理解，我们选择自己实现请求的global ID并在分布式服务调用间进行透传，与ELK（ElasticSearch+Logstash+Kibana）相结合，可以比较清晰的呈现一个外部API请求跨系统服务调用的所有日志。
5. 缓存的使用，对于内容型数据（例如：价格，商品税率），使用Redis缓存，这里特别要注意防缓存穿透（当数据库记录本身不存在每次都穿透缓存去读数据库）；对于配置型数据，使用Local JVM缓存（未使用EhCahce,自己实现MRU和缓存空间设定，主要原因是以前项目有相应的积累，可重用）；对于操作型数据（例如：购物车，库存），使用Redis缓存，操作型数据里，特别是购物车读写同样频繁，在高并发环境下容易因为缓存更新失败而导致缓存和数据库数据不一致，需要使用MQ记录不一致情形并通过Listener应用执行缓存失效。
6. 图片服务器的使用，团队小伙伴以前有大规模应用TFS的经验，给我反馈是TFS算是淘宝开源作品里为数不多的精品，刹那间我是有点心动的。现实马上打醒我，小伙伴需要去做其它更重要的事情，TFS这玩意，等我们图片规模大到一定程度必须自己来做图片服务器和存储系统再考虑吧。于是我们选择了七牛，很完整的图片管理和CDN服务，算下来一年的价格也不贵。当然第三方服务始终是不可靠的，我们也专门引入了assets的业务子系统管理图片及图片在服务器上的元信息，这样在将来比较容易的迁移到其它图片云服务或者自己使用Nginx+TFS。
第二个阶段（4个月）
随着人员的逐步到位，各个业务领域的业务子系统开始铺开进行开发，这个时候如何协调开发人员以统一的风格来实现各个业务子系统就显得格外重要了。而且，在基础框架和工具层面，也要尽量统一，减少维护的成本，所以，我们在开发团队里一直有一个由精兵强将组成的小组负责这一部分。
1. 数据库规范：包括每个业务对象对应的数据库表如何设定主键，唯一ID，唯一性索引，每张数据库的预留字段（创建时间，更新时间，创建人，更新人，乐观锁计数等）。
2. REST API规范：增删改查的URI pattern，特殊POST操作的URI pattern，API版本。
3.&通用参数规范：对语言，货币，请求ID，调用者等的统一命名和处理。
4.&领域边界划分：在划分基础领域边界的基础上，为了提高性能，减少不必要的远程服务调用，在业务允许的情况下，进行一定的冗余。例如：在购物车中不仅仅存储商品SKU ID，还包括商品的名称，商品缩略图链接，店铺名称等信息，避免在查询购物车时再去调用商品API获取这些信息。
5.&异常处理：提供异常基础类，基于异常基础类提供异常处理框架在业务服务层和REST服务层对异常进行统一处理。各业务子系统仅需扩展异常基础类，在业务代码中抛出这些异常即可。异常处理框架帮助处理剩下的事情。这样对于API调用者来说也是极其友好的。
6.&配置管理：在系统还没有发展到一定规模时，可能还不需要一个集中的配置中心。但是，每个业务子系统切忌分散管理配置信息，因为开发，测试，预发布，线上各种环境需要的配置很可能是不相同的，分散管理的配置信息在每次部署一个新的环境简直是噩梦。目前，因为我们已经的系统规模已经发展到10+个业务子系统，即使每个子系统都集中管理配置信息，如何高效的管理各个不同环境的配置信息已经成为一个非常突出的问题，我们基于disconf已经做了POC，计划在下一个阶段把disconf用起来。我本人是Netflix OSS的粉丝，本来Netflix Archiaus是我的首选，但是考虑最近接触的国内开源的工具越来越好，社区也越来越活跃，我们果断的选择了disconf。
7. Session：在这个方面我们是走了一些弯路的，已开始我们有规划专门的session service，并且与shiro做整合，后面的session信息存到Redis中，这个已经基本开发完毕。但是在项目实际演进的过程中，这个阶段我们的前端应用里PC端和移动端商城都是基于PHP开发（基于Yii Framework），在PHP里已经有比较完整的session处理，我们后端的业务服务完全是无状态的，在这里再去使用这个统一的session service反到在项目时间特别紧张的情况下给PHP开发造成很多困扰，所以，我们决定短期内放弃session service，全权交由PHP来处理。在未来系统演进到前段多应用，甚至不同技术栈时在重新把它找回来。
8.&Scheduler和任务处理：对淘宝了解的同学一定听说过他们早期开源的TBScheduler和现在正在使用的TTD，还有最近当当开源的Elastic-Job，可是，对于一个刚刚起步的业务系统，对于这种任务处理还没到需要分布式的地步，所以，我们选择了从Quartz和Spring Batch切入，但是Quartz本身只负责调度本身，我们还是需要存储一些任务的详细信息和状态，要支持异步任务的回调通知状态，排他性任务，已经简单的任务流程编排，我们按照自己的需求，基于Quartz做了扩展支持这些功能。未来如果业务发展需要我们引入分布式任务处理的机制，我想Elastic-Job会是我的第一选择。
9.&统一登录服务：今天我相信在Java的世界里大家要实现统一登录服务大部分人会第一选择会是CAS。CAS对各种认证协议的支持未尝完备，后面也很容易挂自己实现的credential数据库。不过比较讨厌的是，CAS自带前台登录页面，这部分是基于JSP的，而我们的前端工程师全是PHP的，改造起来那叫一个费劲。虽然我们可以放弃它自带的JSP页面直接调用CAS的API，但是处理起来过于复杂，对于我们这个规模有限的初创团队有点不可承受之重。另外，目前我们团队在注册这个环节是直接绕过了CAS调用用户子系统的注册API，对于PHP同学们来讲也是很高兴的。
10. 非Java业务子系统：在电商平台中，从业务需求来讲，促销是非常复杂的一个业务子系统，各种不同的促销条件，促销次数限制，促销之间的互斥和组合，促销金额计算，和优惠券或优惠码结合使用，其实这需要一个高效的规则引擎，一方面能够比较清晰的定义这些规则，另一方面在执行期也能够在毫秒级能够完成对一个订单的促销计算，传统的Java+关系数据库建模是很难搞定的。已开始我们想基于一个开源的规则引擎来做，所以我们队Drools做了一定的研究，作为一个通用的规则引擎，Drools功能比较强大，但是也比较复杂，在我们只有1个开发工程师能铺到这个领域的情况下，也很难搞定；另外，Drools在实时规则计算的效率上也是一个很大的问号，而且促销管理业务工具对我们是非常重要的，基于Drools的规则定义语言来开发这个工具难度太高。我们最终选择了DSL，定义一套促销这个领域的专有语言，用JRuby来实现促销DSL的语义模型和语法解析器，一来Ruby的一些声明式语法特性是非常适合来定义DSL的语义模型和进行语法解析，另一方面JRuby运行在JVM中可以和各种Java库无缝整合。促销引擎分为4个子系统：DSL引擎-负责管理促销DSL定义，解析DSL转化为语义模式；预计算引擎-负责对促销规则进行预计算，将商品和其可能应用的促销进行关联（提高runtime计算的效率）；runtime计算引擎-在线为一个订单计算促销结果。优惠券引擎 – 处理优惠券和优惠码的生成，管理和使用。目前，我们的促销规则DSL定义，预计算结果和优惠券信息均使用MongoDB进行存储。其实即使这样，业务管理工具来管理DSL来表达的促销规则还是一个挑战，我们在两者直接加入了一层meta data层来做映射缓解这个问题，这就意味着业务管理工具只是DSL表达能力的一个子集，对于一些高级的促销，我们直接在工具上开放了DSL编辑器直接对DSL进行编辑。另外，促销引擎的4个子系统都已经利用Docker进行部署，也为我们系统向容器化部署演进打下了基础。
11. 前台商城系统和CMS：本身我自己在CMS上有一些研究，对WordPress, Joomla和Drupal都有一定的了解，加上电商运营的特点，对CMS的要求特别强，我一开始是打算在Drupal上往前走的。而且我们在Drupal上也做了投资，研究学习，POC，前前后后也有小三个月，但是慢慢我也发现一个问题：Drupal本身也是很完整的一个系统，加上生态系统，和电商的领域已经有很多交集，这给我的小伙伴造成了很多困扰，他一直在质疑为什么产品目录树，购物车这些Drupal都有现成的插件我们还要再去实现一套后端服务。虽然从架构上很容易解释，但是现实是当你每天面对这样一个系统时是难免会很纠结的。后来，我们找到了一个既有丰富的Drupal经验，也经历了去Drupal，自主开发CMS的小伙伴，一番沟通和探讨，我们决定放弃Druple，自己干。
我这里贴一下我的小伙伴给我的建议吧：drupal善于做cms，模块固然成熟，但是牺牲了性能为代价。我们的业务场景更加灵活丰富，结合了传统pc，线下收银，以及移动，o2o等各种场景。单纯的依靠定制模块开发将会是事情变得更加复杂且不可控。 采用一个流行且易用的开源框架，使得我们在迅速迭代与稳定架构之间获得了更好的平衡，同时也能更好的结合中国特色的市场需求。通过框架的crud功能，我们迅速完成了传统的cms模块。而通过mvc最流行的业务分层模式，我们更好的通过m层同后台进行了松耦合式的开发体验。使得整个系统既可以脱离应用层纵向拓展，也可以通过其他各种应用层架构（node.js agular.js）实现横向的拓展。drupal的缺点还有一些，比如社区陈旧，模块数量虽多但是优质模块很少。性能上因为其自身机制，当系统复杂之后容易产生性能瓶颈，且不利于开发人员trace。 如果采用drupal，我们将被迫用5-10年的senior phper去学习一个在中国并不流行的技术架构。基本是很难找到人的。换开源php框架之后，那么，只需要有几个senior的开发人员进行组织整体架构并review，就能利用中国大量的码农(coder)。
12. 业务管理工具：AngularJS+Bootstrap，这个应该没有太多争议，虽然现如今React.js如火如荼，可是在我们那个时候Angular还是更靠谱的选择，另外我们的工具应用选用了Spring的AppFuse框架，让他们能够更快速的开发前台工具应用，并方便的处理访问控制，多语言，前后台交互等问题。
单独的话题
1. 单元测试 – 节奏再快，资源再短缺，我还是坚守底线，大家做好UT，而且是基于mock的UT，前期在UT的投资虽然对于快速迭代的节奏来讲往往都会有冲突，可是它带来的后期维护的便捷和高效往往是值得我们付出的。
2. 持续集成 – 从第一天，我们就投入一个专职工程师进行来负责持续集成，Jenkins, Maven repostiory, Git的搭建，持续集成脚本的开发，持续集成流程的建立。这些在很多小团队看来不必要的投资其实随着项目的执行其带来的好处是会不断被放大的。我们采用chef来生成操作系统和中间件级别的标准image（例如：Tomcat, Nginx, MySQL, Redis, MQ, ElasticSearch等等的标准image），但是我们的持续发布脚本并未使用chef来编写，而是直接用ruby来实现的，这个主要原因是直接用ruby提供了更大的灵活性，我们在以前的项目中也有一定的积累。
3. 测试 – 很遗憾，我们的测试资源是在有限，在保系统功能的基本准则下，我们牺牲了API级别的功能测试，前期只能靠UT来保障了。这也有很多无奈，如果有一天测试资源跟上，需要第一时间把API自动化测试，和基于场景的自动化测试不上。
1. 配置中心，目前很痛的一个环节，前文已经提到，我们已完成disconf的POC，接下来就会使用。
2. 服务发现和调用框架：用不用dubbo?其实有其它更轻量的选择（例如：consul做服务注册和发现，hystrix/turbine做故障隔离和服务metris），我们现在的实现已经很小清新。另一个角度dubbo在国内的生态的确不错，基本上主流电商公司都在使用。这个留着慢慢纠结吧。
3. 错误数据校正平台：在高并发的场景总是不可避免出现一些异常情况造成错误数据，建立一套错误数据校正平台是很重要的，要知道客户投诉起来，运营抱怨起来，往往技术团队是最惨的。
4. 全docker化：目前除了促销引擎的4个业务子系统，其他还是使用的青云上的linux虚机，考虑到初期业务不大要节省服务器成本，我们不得不将一些业务子系统合并到一个WAR里面发布，如果每个业务子系统都能够docker化，就不需要这么费劲了。
5. API网关：目前我们的业务服务已经有需求要被外部系统调用（例如：联盟营销系统），如何将内部的业务服务暴露出去变成一个课题，我们需要引入API网关来解决这个问题，目前我们已经开始调研zuul。
6. 多租户模式下不同客户的个性化定制：目前我们只能做到前端商城的个性化定制和外部系统集成的个性化定制，核心业务层如何做个性化定制是需要解决的，我们以前有做传统企业级电商平台的定制框架的经验，但是在SaaS多租户的场景下这个将会是个巨大的挑战。
7. 压测体系：SaaS和传统企业电商平台的压测是很不一样的，如果评估线上环境的容量，如何持续的对线上环境做压测，如何模拟真实流量，现在这些一二线互联网电商平台已经积累了足够的经验，我们要做的，就是一步一步，吸取人家的精华，结合自身的情况，执行起来。
8. 运维体系：这是一个比较大的话题，我们可以单独再讨论。
人打赏支持
码字总数 36274
支付宝支付
微信扫码支付
打赏金额: ￥
已支付成功
打赏金额: ￥}