在北京，java开发，一般50人以内的小公司，一个项目组一年做几个项目(中小型)？_百度知道
在北京，java开发，一般50人以内的小公司，一个项目组一年做几个项目(中小型)？
做OA办公系统的一般做几个项目？电商的又做几个项目呢？给个大概的范围就可以了 ，谢谢。
我有更好的答案
无论是中小型还是大点的公司，都要看项目的大小。一般说来周期小的项目（3月之内），一年下来也就四五个吧。这里面算的不只是开发的时间，还有其他的，比如说后期需求的变更，做出来的项目有些跟客户想要的不是同一结果等等；另一种情况就是产品化的项目，这个周期可能会稍微短一些。希望可以帮到你！
采纳率：60%
为您推荐：
其他类似问题
java的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。阅读时间大约3分钟（914字）
YC孵化的Moltin：只需几行代码就可以给你的应用添加电商功能
Moltin的三位创始人想出了一个办法，解决了他们所面临的根深蒂固的问题，作为2015 YC冬季班的成员，像很多资深会员一样，他们的创业项目从他们自己的需求中诞生。本案中，他们在为英国的一家设计代理机构工作时，发现要给网站添加一个电子商务功能比如购物车实在是太难了，并且经常还很贵。
猎云网3月27日报道
（编译：一水)
Moltin的三位创始人想出了一个办法，解决了他们所面临的根深蒂固的问题，作为2015 YC冬季班的成员，像很多资深会员一样，他们的创业项目从他们自己的需求中诞生。
本案中，他们在为英国的一家设计代理机构工作时，发现要给网站添加一个电子商务功能比如购物车实在是太难了，并且经常还很贵。
为此，他们决定创建一个基于API的框架进行简化，该框架成为日后的Moltin，它的理念是为开发者简化添加电子商务的功能，只要通过几行代码就达到，Moltin的CCO Adam Sturrock解释到。
只要编写一些代码，就可以链接到电商功能，比如链接到购物车或结算页面。对于非技术性的应用，比如给博客添加电子商务组件，也进行了简化，只要创建HTML控件就可以调用。
现在，在平台上有1600位开发者，5或6个实时安装的API，30个左右的API正在开发中，Sturrock指出。
免费试用版可以用于小店和30个API调用，0.2GB存储空间以及一个管理员账号。当要扩大规模时，需要基于调用的API数目及所使用的存储空间按月付费，起价为每月49美元30万个API请求、1GB存储空间和无限制的管理员账户。
Moltin团队还为不同价格的产品内容设计了富于创造性的滑块，只要拉动滑块就可以看到每个价格水准的产品细目了。
在约18个月前，Moltin在英国着手发展，他们加入了名为Ignite 100的加速器项目，并且融到一些钱，增加了一些功能，而后于几个月前搬到了旧金山，成为YC计划的一部分。
事实上，要前往美国，他们需要申请护照，并为加入YC进行面试。
在项目即将结案之际，Sturrock说加入YC是很棒的体验。加入YC不是他们的第一次加速，所以他们原以为他们知道该期待些什么，但实际上YC有点不一样——在好的方式上。
“YC工作起来棒得让人吃惊，”Sturrock说。“长时间的紧张体验里，YC让我们重新思考该如何描述产品，以及更好地进行销售。”
在最初两周过后，YC帮助建出了网站，并让人们登录，还编写了入门指南，让人们能快速上手，并且让服务更加完美。
Sturrock说，YC的合作伙伴一直在尝试销售方法，尝试直接与代理商合作，但发现代理商们更倾向于使用更加成熟的产品，比如Magento或者Shopify。
YC的合作伙伴后来意识到使用产品的开发者们会愿意尝试，因此推出了免费版本。
YC的合作伙伴发现现有的解决方案对开发者而言都太复杂太贵了——并且如果开发者们破坏了自己的解决方案，就要被迫对其进行维护。
而Moltin提供基础构建模块，试图让其对用户而言更简单。
“人们不需要又大又臃肿的系统，”Sturrock说。“我们要让用户用起来不再痛苦。”
Source：TC
想要了解更多创业创新知识，快速添加猎云网微信号：
<div class="module-box mb20" v-for="(item,index) in items" v-if="index
{{item.author_user_sign}}前面写过一些电商网站相关的文章，这几天有时间，就把之前写得网站架构相关的文章，总结整理一下。把以前的一些内容就连贯起来，这样也能系统的知道，一个最小的电商平台是怎么一步步搭建起来的。对以前的文章感兴趣的朋友可以看这个，
本文大纲：
1.&小型电商网站的架构
2.&日志与监控系统的解决方案
3.&构建数据库的主从架构
4.&基于共享存储的图片服务器架构
5.&移动M站建设
6.&系统容量预估
7.&缓存系统
一、小型电商网站的架构
刚从传统软件行业进入到电商企业时，觉得电商网站没有什么技术含量，也没有什么门槛，都是一些现有的东西堆积木似的堆出来罢了。然而，真正进入到这个行业之后，才发现并非如此。有人说过，好的架构，是演化出来的，电商网站的架构也是如此。现在好的电商网站，看似很复杂，很牛逼，其实也是从很小的架构，也是从没什么技术含量开始的。所以，架构的演化过程，就是在技术团队不断追求极致的过程。
今天就来总结小型电商网站的架构演进。一套电商系统最初期的架构，往往会采用一个比较典型的LAMP架构，前端加上Apache/PHP，后端是MySQL。这个算是比较流行的。不过，目前还有一套.net的技术架构，可能大家很少提到。很不幸，我就是在一个.net平台为基础的电商公司。所以，今天也是要总结.net&平台的电商架构。
一般初期的电商网站，基本就几个业务子系统：网站前台、商家前台、系统管理后台、App、M站等。业务量也不是很大。所以，MVC&+&缓存&+&数据库基本就搞定了。
单就开发效率而言，.net&MVC&的技术架构不会比LAMP开发速度慢。所以，一些企业，为了快速推出自己的电商平台，也会采用.net&架构。
上图为基础架构层面。这是一个很简单的基础架构。
前端网站和M站，考虑到访问量和系统的可用性，基本会采用分布式部署。通过代理服务器进行请求分发。
其它的业务子系统，像商家前台和管理系统，基本上都是单机或是主从部署。
各个DB&，Redis&服务和文件和图片服务，搜索引擎Solr服务等，采用主从部署。
整个系统架构里面，还有一个比较重要的组成部分，那就是监控系统。例如：流量监控、硬件监控、系统性能监控等， 还有就是对某个页面进行监控，设置页面的其中一块进行监控等。它是提高整个平台可用性的一个重要手段。多平台、多个维度的监控，能够确保系统的可用性。一旦出现异常，特别在硬件或者性能方面出现异常，监控系统也能立刻发出警告，这样也好防范于未然。
总而言之，一个好的系统架构应该从扩展性、安全性、性能和可靠性来考虑。罗马不是一天建成的，架构适合就行，可以先行之而后优。通过渐进演化的过程，逐步让系统越来越完善。
二、日志与监控系统的解决方案
监控系统主要用于服务器集群的资源和性能监控，以及应用异常、性能监控、日志管理等多维度的性能监控分析。一个完善的监控系统和日志系统对于一个系统的重要性不必多说。总之，只有实时了解各系统的状态，才能保证各系统的稳定。
如上图所示，监控平台监控的范围很广，从服务器性能及资源，到应用系统的监控。每个公司都有特定的平台统一监控的需求及解决方案，但监控平台的任务和作用基本是一致的。
日志是监视程序运行的一种重要的方式，主要有两个目的：1.bug的及时发现和定位；2.显示程序运行状态。
正确详细的日志记录能够快速的定位问题。同样，通过查看日志，可以看出程序正在做什么，是不是按预期的设计在执行，所以记录下程序的运行状态是必要的。这里将日志分为两种：1.异常日志；2.运行日志。
我们主要是使用log4net，将各个系统的日志，持久化记录到数据库或者文件中，以方便后续的系统异常监控和性能分析。如何集成log4net，这里不多说。
日志记录的几个原则：
日志级别一定要区分清楚，哪些属于error、warning、info等。
记录错误的位置。如果是分层系统，一定要在某个层统一处理，例如我们的MVC架构，都是在各个Action中Catch异常并处理，而业务层和数据库层这些地方的异常，都是Catch到异常后，往上一层抛。
日志信息清晰准确有意义，日志尽量详细点，以方便处理。应该记录相关系统、模块、时间、操作人、堆栈信息等。方便后续处理。
监控系统是一个复杂的系统平台，目前有很多的开源产品和平台。不过我们平台小，监控任务和需求少，所以基本都是自己开发。主要有这五个方面：1.系统资源；2.服务器；3.服务；4.应用异常；5.应用性能。
具体的架构图如下：
1）系统资源监控
监控各种网络参数和各服务器相关资源（CPU、内存、磁盘读写、网络、访问请求等），保证服务器系统的安全运营，并提供异常通知机制以让系统管理员快速定位/解决存在的各种问题。目前比较流行的应该是Zabbix。
2）服务器监控
服务器的监控，主要是监控各个服务器、网络节点、网关等网络设备的请求响应是否正常。通过定时服务，定时去Ping各个网络节点设备，以确认各网络设备是否正常。如果哪个网络设备出现异常，则发出消息提醒。
3）服务监控
服务监控，指的是各个Web服务、图片服务、搜索引擎服务、缓存服务等平台系统的各项服务是否正常运行。可以通过定时服务，每隔一段时间，就去请求相关的服务，以确保平台的各项服务正常运行。
4）应用异常监控
目前我们平台所有系统的异常记录，都记录在数据库中。通过定时服务，统计分析一段时间之内的异常记录。如果发现有相关重要的模块的系统异常，比如支付、下单模块频繁发生异常，则立即通知相关人员处理，确保服务正常运行。
&5）应用性能监控
在API接口和各应用的相关位置进行拦截和记录下程序性能（SQL性能，或是 程序执行效率）。相关重要模块提供性能预警，提前发现问题。&同时统计相关监控信息并显示给开发的人员，以方便后续的性能分析。
三、构建数据库的主从架构
发展到大型成熟的公司之后，主从架构可能就有点落伍了，取而代之的是更加复杂的数据库集群。但作为一个小型电商公司，数据库的主从架构应该是最基础的。任何大型的系统架构，都是不断演进的。主从架构便是数据库架构中最基础的架构。所以研究完主从架构，也就能看懂更加复杂的架构了。
首先为什么要读写分离？
对于一个小型网站，可能单台数据库服务器就能满足需求。但在一些大型的网站或者应用中，单台的数据库服务器可能难以支撑大的访问压力，升级服务器性能成本又太高，所以必须要横向扩展。还有就是，单库的话，读、写都是操作一个数据库。数据多了之后，对数据库的读、写性能就会有很大影响。同时对于数据安全性和系统的稳定性也是挑战。
数据库的读写分离的好处？
将读操作和写操作分离到不同的数据库上，避免主服务器出现性能瓶颈；
主服务器进行写操作时，不影响查询应用服务器的查询性能，降低阻塞，提高并发；
数据拥有多个容灾副本，提高数据安全性，同时当主服务器故障时，可立即切换到其他服务器，提高系统可用性。
读写分离的基本原理就是让主数据库处理事务性增、改、删操作（Insert、Update、Delete）操作，而从数据库处理Select查询操作。数据库复制被用来把事务性操作导致的变更同步到其它从数据库。
以SQL为例，主库负责写数据、读数据。读库仅负责读数据。每次有写库操作，同步更新到读库。写库就一个，读库可以有多个，采用日志同步的方式实现主库和多个读库的数据同步。
1SQL Server 读写分离的配置
SQL Server提供了三种技术，可以用于主从架构之间的数据同步的实现：日志传送、事务复制和SQL 2012 中新增的功能Always On 技术。各自优劣，具体的大家自己去百度吧，这里提供网上的朋友的配置方式，仅供参考。
日志传送：SQL Server 2008 R2 主从数据库同步
（链接：）
事务复制：SQL Server 复制：事务发布
（链接：）
（图源：网络）
2C# 数据库读写操作
C#的请求数据库操作，单数据库和主从架构的数据库还是不一样的。主从架构的数据库，为了保证数据一致性，一般主库可读可写，从库只负责读，不负责写入。所以，实际C#在请求数据库时，要进行区别对待。
最简单的就是：配置两个数据库连接，然后在各个数据库调用的位置，区分读写请求相应的数据库服务器，如下图：　
第二种解决方案就是判断SQL语句是写语句（Insert 、Update、Create、 Alter）还是读语句（Select）。
Demo下载：
（PS：此Demo为本人总结，跟实际生产中的DLL 不太相同，但原理是一样的，大家总结封装吧）
同时，增加相关的数据库配置
四、基于共享存储的图片服务器架构
在当前这个互联网的时代，不管何种网站，对图片的需求量越来越大。尤其是电商网站，几乎都会面临到海量图片资源的存储、访问等相关技术问题。在对图片服务器的架构、扩展、升级的过程中，肯定也会碰到各种各样的问题与需求。当然这并不代表，你就必须得弄一个特别NB的图片服务架构，只要简单、高效、稳定就行。这部分我们来总结一个特别简单、高效的图片服务架构：通过共享存储的方式来实现图片服务架构。
然而，也有一些人问我，现在大型网站的图片服务器的架构已经完全不是这样了，别人家的图片系统比你这个牛逼多了，为啥不直接写那个呢？&
事实是：第一，大型牛逼的系统我也不会；第二， 再牛逼的系统也是从小的架构演化过去的，没有一步到位的。这里介绍图片服务器架构虽然比较简单，但也是经过了单机时代的演化了，基本上可以满足中小型分布式网站的需求。这种架构的搭建和学习成本都极低，符合目前“短平快”的开发模式。
通过共享目录的方式实现共享存储 ，在共享目录文件服务器上配置独立域名，这样可以将图片服务器和应用服务器进行分离，来实现独立图片服务器。
1. 将图片服务和应用服务分离，缓解应用服务器的I/O负载。
2. 通过共享目录的方式来进行读写操作，可以避免多服务器之间同步相关的问题。
3.&相对来讲很灵活，也支持扩容/扩展。支持配置成独立图片服务器和域名访问，方便日后的扩展和优化。&
4.&相对于更加复杂的分布式的NFS系统，这种方式是性价比高，符合目前互联网的“短平快”的开发模式。
1. 共享目录配置有些繁琐。
2.&会造成一定的（读写和安全）性能损失。
3.&如果图片服务器出现问题，那所有的应用都会受到影响。同时也对存储服务器的性能要求特别高。
4.&图片上传操作，还是得经过Web服务器，这对Web服务器还是有巨大的压力。
架构非常简单，基本架构如下图所示：
在存储服务器上建立一个共享目录（具体方式，我就不去重复了，自己百度吧，注意共享目录的文件安全）。
各个应用直接通过共享目录（\\192.168.1.200），将图片上传到存储服务器上。
建立一个Web站点（i1.abc.com）将该共享目录通过Web站点发布出去。这样其它的应用就能访问到相关图片。
所以，各应用将文件上传到共享目录
&&&&//保存原图　　　　//完整的地址：\\192.168.1.200\lib\\10\IMG\4ugvvt6m9gdu.jpg　　　　relativePath = relativeDir + fileName + imageE
&&&&&&&var absolutePath = ConfigHelper.SharePath + relativeP
&&&&&&&fileData.SaveAs(absolutePath); &&&&&&&&&&&&
上传成功后，可直接通过web 的方式访问：
http://i1.abc.com/lib//10/IMG/4ugvvt6m9gdu.jpg
五、移动M站建设
最近在一直在搞M站，也就是移动Web站点。由于是第一次，也遇到了很多问题，所以把最近了解到的东西总结一番。聊一聊什么是移动M站，以及它有什么作用和优势。
有人会问，M站和APP有什么不同？
APP直接在用户的移动设备上，曝光率相对较高。 而M站需打开浏览器，输入地址才能访问，所以曝光率相对较低。
M站的推广的渠道相比移动APP，渠道较多，方便追踪用户来源、流量入口等，方便以后的活动推广和数据分析。
M站用户无需安装，输入URL即可访问，而APP需要下载安装。
M站能够快速地通过数据分析，能快速得到用户的反馈，从而更容易根据统计数据分析和用户的需求来调整产品。
APP对用户更具粘性及用户体验也更好。
M站对于营销推广活动非常方便，转发分享方便快捷。
M站更新迭代产品速度和响应产品调整非常快，随时发布，而APP需要审核时间。
M站跨平台，无需开发安卓和iOS版，只需有浏览器即可。&&&&&
所以， 我觉得，M站和客户端是相辅相成的。M站的及时性和快捷性，是APP无法比拟的。而APP的用户体验，则是M站无法做到的。目前来说两者是不可能被对方完全替代的，在互联网营销大行其道的今天，M站也越来越重要。营销活动大多以H5页面的形式展示和传播。通过M站的营销和推广，从而又促进APP的使用和推广。
目前，移动M站有倾向APP的趋势。M站会越来越像个APP，使得M站也越来越重要。而且，很多APP的展示效果，在原生代码无法实现的时候，嵌套移动H5页面也是一个很好的选择。
下面介绍几个移动M站建设的要点：
51Degrees号称是目前最快、最准确的设备检测的解决方案。它是一个免费开源的.NET移动应用开发组件，可以用来检测移动设备和浏览器。甚至可以获取屏幕尺寸、输入法、加上制造商和型号信息等。从而可以选择性地被定向到为移动设备而设计的内容。由于拥有精确的移动设备的数据，所以几乎支持所有的智能手机，平板电脑等移动设备。
其实说白了，51Degree的作用就是识别客户端的设备。PC浏览器访问，就跳转到PC站，手机浏览器访问就跳转到M站。从而达到更好的用户体验。
如何将51Degree加入到现有网站？
移动Web和传统的Web其实并没有本质的区别。说白了还是一个Web站点，使用的技术都是Html+CSS+JS。不同的是，只不过目前在Html5的大趋势下，将Html5加入到了移动M站，使得M站更像个轻APP。
3Bootstrap
Bootstrap就不多说了，网上有很多Bootstrap的资料。它最大的优势应该就是非常流行，非常容易上手。如果缺少专业的设计或美工，那么Bootstrap是一个比较好的选择。他的用法极其简单，几乎没什么学习成本，绝对是快速开发的利器。
官网：Github：
移动M站的URL要尽量和PC相同，这是可以避免同一URL在PC站可以显示，但是在手机上打开却是404；
M站写单独的TDK。
六、系统容量预估
电商公司的朋友，这样的场景是否似曾相识：
运营和产品神秘兮兮的跑过来问：我们晚上要做搞个促销，服务器能抗得住么？如果扛不住，需要加多少台机器？
于是，技术一脸懵逼。
其实这些都是系统容量预估的问题，容量预估是架构师必备的技能之一。所谓，容量预估其实说白了就是系统在Down掉之前，所能承受的最大流量。这个是技术人员对于系统性能了解的重要指标。常见的容量评估包括流量、并发量、带宽、CPU、内存 、磁盘等一系列内容。这部分来聊一聊容量预估的问题。
1几个重要参数
QPS：每秒钟处理的请求数。
并发量：&系统同时处理的请求数。
响应时间：&&一般取平均响应时间。
很多人经常会把并发数和QPS给混淆了。其实只要理解了上面三个要素的意义之后，就能推算出它们之间的关系：QPS =&并发量&/ 平均响应时间。
2容量评估的步骤与方法
1）预估总访问量
如何知道总访问量？对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，有什么好方法？
最简单的办法就是：询问业务方，询问运营同学，询问产品同学，看产品和运营对此次活动的流量预估。
不过，业务方对于流量的预估，应该就PV和用户访问数这两个指标。技术人员需要根据这两个数据，计算其他相关指标，比如QPS等。
2）预估平均QPS
总请求数=总PV*页面衍生连接数
平均QPS =&总请求数/总时间
比如：活动落地页1小时内的总访问量是30w PV，该落地页的衍生连接数为30，那么落地页的平均QPS=(30w*30)/(60*60)=2500。
3）预估峰值QPS
系统容量规划时，不能只考虑平均QPS，还要考虑高峰的QPS，那么如何评估峰值QPS呢？
这个要根据实际的业务评估，通过以往的一些营销活动的PV等数据进行预估。一般情况下，峰值QPS大概是均值QPS的3-5倍，如果日均QPS为1000，于是评估出峰值QPS为5000。
不过，有一些业务会比较难评估业务访问量，例如“秒杀业务”，这类业务的容量评估暂时不在此讨论。
4）预估系统、单机极限QPS
如何预估一个业务，一个服务器单机的极限QPS呢？
这个性能指标是服务器最基本的指标之一，所以除了压力测试没有其他的办法。通过压力测试，算出服务器的单机极限QPS 。
在一个业务上线前，一般都需要进行压力测试（很多创业型公司，业务迭代很快的系统可能没有这一步，那就悲剧了），以APP推送某营销活动为例（预计日均QPS为1000，峰值QPS为5000），业务场景可能是这样的：
通过APP推送一个活动消息；
运营活动H5落地页是一个Web站点；
H5落地页由缓存Cache和数据库DB中的数据拼装而成。
通过压力测试发现，Web服务器单机只能抗住1200的QPS，Cache和数据库DB能抗住并发压力（一般来说，1%的流量到数据库，数据库120 QPS还是能轻松抗住的，Cache的话QPS能抗住，需要评估Cache的带宽，这里假设Cache不是瓶颈），这样，我们就得到了Web单机极限的QPS是1200。一般来说，生产系统不会跑满到极限的，这样容易影响服务器的寿命和性能，单机线上允许跑到QPS=960。
扩展说一句，通过压力测试，已经知道Web层是瓶颈，则可针对Web相关的方面做一些调整优化，以提高Web服务器的单机QPS 。
还有压力测试工作中，一般是以具体业务的角度进行压力测试，关心的是某个具体业务的并发量和QPS。
5）回答最开始那两个问题　
需要的机器=峰值QPS/单机极限QPS
好了，上述已经得到了峰值QPS是5000，单机极限QPS是1000，线上部署了3台服务器：
服务器能抗住么？ -& 峰值5000，单机1000，线上3台，扛不住
如果扛不住，需要加多少台机器？ -& 需要额外2台，提前预留1台更好，给3台保险
需要注意的是，以上都是计算单个服务器或是单个集群的容量。实际生产环境是由Web、消息队列、缓存、数据库等等一系列组成的复杂集群。在分布式系统中，任何节点出现瓶颈，都有可能导致雪崩效应，最后导致整个集群垮掉&（“雪崩效应”指的是系统中一个小问题会逐渐扩大，最后造成整个集群宕机）。
所以，要了解规划整个平台的容量，就必须计算出每一个节点的容量。找出任何可能出现的瓶颈所在。
七、缓存系统
对于一个电商系统，缓存是重要组成部分，而提升系统性能的主要方式之一也是缓存。它可以挡掉大部分的数据库访问的冲击，如果没有它，系统很可能会因为数据库不可用导致整个系统崩溃。
但缓存带来了另外一些棘手的问题： 数据的一致性和实时性。例如，数据库中的数据状态已经改变，但在页面上看到的仍然是缓存的旧值，直到缓冲时间失效之后，才能重新更新缓存。这个问题怎么解决？
还有就是缓存数据如果没有失效的话，是会一直保持在内存中的，对服务器的内存也是负担，那么，什么数据可以放缓存，什么数据不可以，这是系统设计之初必须考虑的问题。
什么数据可以放缓存？
不需要实时更新但是又极其消耗数据库的数据。比如网站首页的商品销售的排行榜，热搜商品等等，这些数据基本上都是一天统计一次，用户不会关注其是否是实时的。
需要实时更新，但是数据更新的频率不高的数据。
每次获取这些数据都经过复杂的处理逻辑，比如生成报表。
什么数据不应该使用缓存？
实际上，在电商系统中，大部分数据都是可以缓存的，不能使用缓存的数据很少。这类数据包括涉及到钱、密钥、业务关键性核心数据等。总之，如果你发现，系统里面的大部分数据都不能使用缓存，这说明架构本身出了问题。
如何解决一致性和实时性的问题？
保证一致性和实时性的办法就是：一旦数据库更新了，就必须把原来的缓存更新。
说一说我们的缓存方案：我们目前的缓存系统：Redis（主从）+ RabbitMQ + 缓存清理服务组成，具体如下图：
缓存清理作业订阅RabbitMQ消息队列，一有数据更新进入队列，就将数据重新更新到Redis缓存服务器。
当然，有些朋友的方案，是数据库更新完成之后，立马去更新相关缓存数据。这样就不需要MQ和缓存清理作业。不过，这同时也增加了系统的耦合性。具体得看自己的业务场景和平台大小。
以上均为个人经验分享，不足之处请大伙轻点拍砖，有更好的建议欢迎留言。
阅读(...) 评论()电子商务系统项目的各个组件的实现及UML组件图设计实例_百度文库
您的浏览器Javascript被禁用，需开启后体验完整功能，
享专业文档下载特权
&赠共享文档下载特权
&10W篇文档免费专享
&每天抽奖多种福利
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
电子商务系统项目的各个组件的实现及UML组件图设计实例
互联网从业者|
总评分3.8|
用知识赚钱
&&电子商务系统项目的各个组件的实现及UML组件图设计实例
试读已结束，如果需要继续阅读或下载，敬请购买
定制HR最喜欢的简历
你可能喜欢注册 | 登录
公众号：倔牛的人生
零基础学产品，BAT产品总监带，2天线下集训+1年在线课程，全面掌握优秀产品经理必备技能。
之前，已经写过两篇电商入门的文章，第一篇是让大家从线下到线上对比以期了解电商的基本知识，第二篇分析了电商网站的灵魂——购物车（别怪我隐藏了另外一个的灵魂——搜索，要吃透、说透搜索功能，真心不是一日之功，各位一定要等我~），今天这篇文章将讲述一下电商网站的主元素：各频道、专题页等等的配置发布后台——CMS。
CMS（Content Management System），顾名思义，即内容管理系统。各大新闻网站、电商平台、个人博客等等都可以采用CMS进行建站，但是今天仅说CMS在电商领域中的应用，CMS在电商领域主要是解决一次开发，灵活运营的问题（动态配置C端页面）。
1、CMS之关于“千人千面”的猜想
京东、淘宝C端绝大部分页面也可以看成是由一个大型的CMS配置生成。在我看来CMS的核心只有两点：内容创建和内容发布，简单来说就是按照一定规则创建一条内容，然后发布到指定位置的过程。
在电商发展初期，没有用户数据积累，用户标签体系（用户画像）没有建立起来的时候，CMS相对简单，内容创建靠运营手工填入、手动发布；而在当下，像京东、淘宝这种大型电商平台，我估计CMS应该对接了素材中心（后台商品中心、营销中心、广告中心等）、大数据分析中心（用户标签体系、用户行为数据等 [会员中心]），通过CMS与素材、数据中心连接就能实现自动生成前台频道等页面，做到千人千面，让不同类型的用户看到不同内容的首页。
我从产品的角度画了一个“千人千面”大致实现流程，如果有纰漏，请读者们指正。
上文说CMS最核心的两部分是内容创建和内容发布。如上图，在这个猜想中，当决定用机器取代人工时，就必须要解决自动创建内容的问题，也即解决这两个问题：①内容选取标准是什么？（大数据分析中心）②内容从哪儿来？（素材中心）
以上仅是我的一个猜想，希望大家辩证的去看这个问题。另外，想补充一点是在绝大部分应用场景下，CMS经过二次开发之后已经不是传统意义上的CMS了（经典的CMS比如WordPress、帝国等等），大家只要记住上文说的这句话：CMS最核心的两部分是内容创建和内容发布。
下面开始进入正题，会有这么几个方面的内容：
从业务流程角度，看电商CMS如何动态化配置前台页面；
抽象出电商CMS的页面动态化配置逻辑；
电商网站有哪些元素可动态化配置。
补充说明下，本文不会在按钮功能操作这种颗粒度上进行分析，我想一个产品最重要的是思路和业务流程分析，功能操作只是帮助业务流程顺利流转。举个例子：在售后系统中，用户退货时，仓库管理员必须有一个‘验货’的按钮操作，当仓库管理员确定验货通过后，才会有之后的退款步骤。
2、CMS如何动态化配置前台页面
写这一部分之前，先给大家看一看电商CMS究竟在解决一个什么样的问题，看下图：
这张图看起来很抽象，但是不妨碍理解，建议去看一些电商网站帮助脑补一下。这张图里其实涵盖了很多内容，比如说楼层模板（或者叫组件，想想拼图，一个完整的图由很多组件组成，一个网站也是由很多组件拼凑而成的，CMS其实就是一个拼合组件并发布出去的工厂）。需要提醒的是大家不要被这一个案例图给局限了思维，CMS可动态化配置的内容远远不止于此，第5部分将有相关介绍。
那么，回到问题本身，利用CMS，运营想要在楼层A之前增加一个楼层C，这里面涉及到几个问题呢？
运营想强推的商品是什么？（不同的商品，需要突出的重点信息不一样，选择的模板也不一样）
运营选择什么样的模板？（有多样的模板供选择，这里自然牵扯出了CMS中有一个模板库的概念，模板越多运营起来越灵活）
运营如何把数据录入模板当中？
运营如何将创建好的内容发布到前台网站？（中间一般还需要分多重角色，运营专员负责数据录入，审核专员负责审核发布，这里会牵扯到数据权限的一些概念，不多说了，电商后台数据操作权限界定，是非常重要的一个点，三言两语说不清楚，大家感兴趣可以自行去了解一下）。
从这四个问题中可以抽象出这么一个工作流程：选择模板》数据录入（》内容审核）》内容发布
关于内容发布先多说一点，内容发布有一个点是将内容发布到哪儿？可以是同一个端（PC、APP、H5端等）的不同页面（涉及到模板复用的概念，这可以帮助运营减轻很多工作量）；也可以是不同端，比如我在APP上用了一个模板，能不能直接复用到H5上去呢？在初创公司里，更多的应该去考虑这些问题，因为初创公司就没有太多的运营团队，不同端分开运营成本太高了。这种方案默认一个楼层只有一个模板，因此而忽略了位置这个概念（因为在这里位置 = 楼层）。当然，还需要设置模板的顺序（一般用阿拉伯数字大小排序），这个顺序决定了它在前台展示在第几个楼层。
淘宝店铺装修（它是一个典型的电商CMS）就强调了位置这个概念，可以看看下图红框强调的部分：
看得出有这几个概念：页面总宽度、容器宽度（位置）、页面总宽度 = 容器宽度1 + 容器宽度2 + ……
之后的内容就统一按照方案1的模式，默认一个楼层一个模板描述。另外，大家感兴趣可以注册一个淘宝店铺，如果你是初创电商公司，在淘宝店铺CMS的基础上做减法就够了（模块拖拽的方式也可以暂时绕过）。
3、电商CMS页面的动态化配置逻辑
第3部分实际上已经抽象出了电商CMS的业务流程：选择模板》数据录入（》内容审核）》内容发布
用电商首页来举例，一个电商首页的构成大致如下图所示：
整站分类列表在我看来是一个挂件，它一般悬浮在轮播图上方（页面左侧）。我们绕过这些写死的页头、页尾以及挂件一般的分类列表，现在只说楼层这一部分。接下来，假设把首页简化成是由多个楼层构成，首页动态化配置逻辑大致如下所示：
需要多说一点的是，由首页配置的模式可以推及更多页面的配置模式，套路都是一样的。从上图也可以看出来，关于CMS，一直没有脱离上文说的：CMS最核心的两部分是内容创建和内容发布。
在第1部分，也提到CMS在电商领域主要是解决一次开发，灵活运营的问题，到这里相信大家也可以看出来了，利用CMS搭建一个电商网站的好处是运营不需要因为想新发布一个营销页面来争取开发资源，而开发只需要不断的造模板去满足运营需求，至于产品呢？产品就需要考虑电商网站的灵活性问题，怎么最大化让所有位置都成为可配置？这可能是产品经理需要考虑的产品迭代方向。（当然，创新营销玩法也是电商产品需要不断思考的问题。）
那么，怎么最大化让所有位置（场景）都成为动态化配置的呢？
4、CMS可配置的电商网站元素
第4部分最后一个问题，其实应该改成如果CMS是一个C端页面展现的最终输出口，那么应该控制哪些元素的输出？举个例子，商品详情页有一个商品参数，先看看下图（其实用3C举例更好些哈，大家研究的时候，去研究3C吧~）：
鞋这个分类的商品可能有多个商品参数（导致需要折叠），那么优先展示哪些参数呢？另外，后台对于鞋的描述可能字段（参数）更多，那么哪些字段（参数）可以输出呢？不同分类的商品展示字段也不一样，是不是需要分类进行配置展示呢？
以上的例子，也归属于CMS动态化配置的范畴，这和用户体验相关啊，试想产品设计时，把这个商品有关的全部字段都吐出来，用户不会懵圈么？
举这个例子只是为了说明一下，CMS的动态化配置不仅仅只是局限于频道页（特别是首页）以及活动专题页这些。
本来想在这一部分画一个脑图，苦思之后发现还是脱离不了第4部分，首页构成那种形式，所以也就不画了得了，第5部分也就写到这里。
如果，大家还有什么疑问或者想要我系统补充的，欢迎大家留言我，也欢迎大家和我一起交流。
电商靠运营，运营靠多样化的模板库，CMS看来是电商平台不可或缺的系统了。
作者：QJQ，微信公众号：倔牛的人生
本文由 @QJQ 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Pixabay，基于 CC0 协议
赞赏是对原创者的最大认可
赞赏4人打赏
收藏已收藏 | 35赞已赞 | 13
公众号：倔牛的人生
产品经理群
运营交流群
品牌营销群
文案交流群
Axure交流群
关注微信公众号
大家都在问
51个回答54人关注
7个回答7人关注
13个回答28人关注
18个回答21人关注
20个回答24人关注
30个回答53人关注}