开发一个猪八戒网站，大约需要多少或者自己请程序员，需要什么程序员，多少程序员能完成

现在的猪八戒网站可以说很完善了，要搞出这么一个网站的话，花费太大了，没有几十万，怕是没人做，自己请程序员的话，初期能做出一个不完善的产品，后期还需要维护，更新的，没有几年也完善不了，程序员的工资也是一笔很大的开销。

写网站，特别是这样的大型网站，需要的程序员，大致有：

美工

html制作员

后台代码编写人员

项目策划人员

后期人数多了的话，服务器的承载能力也需要处理，这时候又需要C/C++这样的种程序员。

纯属个人观点，不喜勿喷哦

epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般 *** 作系统均有实现。

网上现在关于这两者不同的介绍已经到处都是了。我这里也不能多说出什么东西，只是记录下我看了实现代码之后的一些总结。

两者的使用场景一般是通过一个入口能够同时监控多路I/O。一般使用的接口，

epool就是

int epoll_wait(int epfd, struct epoll_event events, int maxevents, int timeout);

select为：

int select(int nfds, fd_set readfds, fd_set writefds, fd_set exceptfds, struct timeval timeout);

通过上述两个函数能够将调用线程阻塞，线程变为可执行条件有两种情况：

无任何事件发生，超时时间已过

在所控制的I/O有事件到来

epoll_wait函数中看不到相关的监控信息，因为是通过epoll_ctl已经加入，而select之间在函数调用中由（fd_set readfds, fd_set writefds, fd_set exceptfds）传入。epoll_wait饭互结果通过events返回，而select的传入参数也是传出参数。两者传出参数均表示发生事件的对应I/O标识。

两种方式的区别主要体现在以下几个方面：

select所能控制的I/O数有限，这主要是因为fd_set数据结构是一个有大小的，相当与一个定长所数组。

select每次都需要重新设置所要监控的fd_set（因为调用之后会改变其内容），这增加了程序开销。

select的性能要比epoll差，具体原因会在后续内容中详细说明。

嗯，说道这个为什么select要差，那就要从这个select API说起了。这个传进去一个数组，内部实现也不知道那个有哪个没有，所以要遍历一遍。假设说我只监控一个文件描述符，但是他是1000。那么select需要遍历前999个之后再来poll这个1000的文件描述符，而epoll则不需要，因为在之前epoll_ctl的调用过程中，已经维护了一个队列，所以直接等待事件到来就可以了。

Linux中select此段相关代码为：

/ 遍历所有传入的fd_set /

for (i = 0; i < n; ++rinp, ++routp, ++rexp) {

unsigned long in, out, ex, all_bits, bit = 1, mask, j;

unsigned long res_in = 0, res_out = 0, res_ex = 0;

const struct file_operations f_op = NULL;

struct file file = NULL;

in = inp++; out = outp++; ex = exp++;

all_bits = in | out | ex;

/ 此处跳无需监控的fd， 白白的浪费时间啊…… /

if (all_bits == 0) {

i += __NFDBITS;

continue;

}

/ 后续进行一些相关 *** 作 /

}

而epoll则无需进行此类 *** 作，直接检测内部维护的一个就绪队列，如果队列有内容，说明有I/O就绪，那么直接赋值返回内容，成功返回，如果没有成功，那么睡眠，等待就绪队列非空。

通过这个两者的比较，其实两者的差距啊，大部分是因为这个API设计所决定的，select就设计成这样一个API，内部再怎么优化也只能是这么个烂样子，而epoll这样维护与等待分离，灵活多变，最后也就带来了相对的高性能，以及可扩展性。

我个人觉得没有那个必要。

从开发经验上，你可以找找当下流行的js库，以及很多网站的js来看看，并没有人那么做过。

速度上，如他的上层中没有绑定事件，那么他几乎不需要什么开销就能完成DOM树的冒泡，你鼠标在页面上动的时候，不停的触发mouseover事件，那也没见浏览器被卡死，对吧？

如果上层绑定了事件，试问你把事件停止了，别的程序员定义的事件还能执行吗？

举个例子，在table中点击一个td一行tr都变成**，如果你td再加了一个事件，点击的时候出现一个编辑框编辑这个td的值，而你刚好在这个td中停止了冒泡，那试问tr变成**的事件怎么保证？

js开发往往都是有开发通用组件的人员，有开发页面功能的人员，除非你明确的要求不去执行父亲节点的定义的事件，否则最好不要去阻止其冒泡！

前言

我们已经 设计和构建 了十多年的软件，大部分时间我们一直在使用优秀的 Symfony 框架来实现这一目标。 Symfony 是一个传统的单体 PHP 构件集，受 Java Spring 的启发，我们发现它非常适合 企业 Web 应用程序 和 数字产品 的快速开发，而这些正是我们主要经济来源。

然而，去年发布的 Symfony 4 代表了该框架的重点逐渐变化 ; 这变化体现在其远离单体架构和向 微服务 靠拢，这种变化背后的方法论在过去几年中越来越受欢迎。

为了说明这一转变，新版本在默认情况下使用了微内核（micro by default), Symfony 组织大力宣传其新的微内核设计，声称与 Symfony 3 相比，编写应用程序所需的代码减少了 70%。

除了这些优点外，这一变化意味着运行单个应用程序的开销要小得多，这使得 Symfony 对于微服务体系结构的使用更具吸引力。

什么是单体应用和微服务

微服务设计基于将大型传统（单体）应用程序拆分为几个小型、不同的应用程序的概念。这些应用程序将处理单个业务功能领域，并与其他组件协作，就像它们是第三方应用程序一样

这真的是一个新事物吗，或者这只是一个具有时髦名字的面向服务体架构（SOA) 我们不会在这里进行辩论，毕竟你可以到 Slashdot 和 Hacker News 上讨论这个问题。不过，我们要说的是，微服务方法 ( 或者随便你怎么称呼它 ) 主要对大型组织有益。这是因为非常大的应用程序可以被分割成几个不同的服务，每个服务由各自独立的开发团队管理。

微服务体系结构的另一个好处是允许灵活地扩展一个特定组件的数量，而不是整个应用程序。这特性非常适合应用在 d性云计算 ，但在大多数情况下，我认为这种效率提高会被一个大而突出的问题所淹没。

你真的需要微服务

我的观点是，除非你在 Google 或 Netflix 等拥有数百名软件开发人员的公司工作，否则你可能不需要微服务。事实上，对于大多数中小型企业来说，采用这种设计可能非常不合适。

我将会讲到一些例外，但是微服务的开发和维护成本是很多人都注意到的却又很少谈及的问题。我们可以用一个简单的问题来决定是否适合把微服务作为你的起点 : （译者注：这句子的原文中有个词语叫 房间里的大象 ，是指所有人都注意到却又不被提及的问题）

你系统中的某个组件（例如用户管理）是否足够复杂，以致于需要多个开发人员全职进行持续开发？

如果答案是否定的，那么微服务方法可能会浪费您的时间和金钱。相反，如果你足够幸运，能够在以后达到这个规模，你可能就可以慢慢地把那些需要多人开发的部分分离出来。

为什么微服务在开发和运维上开销更大

由于您不需要处理大量的分布式系统问题，因此单体应用程序通常是一个开销更少的方案。使用像 Symfony 这样的单体框架所通过提供开箱即用的集成特性提供了许多好处，这些特性可以方便地从应用程序的所有区域访问。你基本上可以避免处理以下的这些问题 :

例外情况（混合的方式）

有时候微服务是合适的，但是根据我的经验，在这些情况下，可伸缩性需求或容错需求超过了必须设计和管理分布式系统的缺点。这里的一个很好的例子是像 Monzo Bank 这样的企业应用，它既需要能够立即按需求进行伸缩，又需要能够确保系统某个区域的故障不会影响到另一个区域

我们在 Browser 中多次重复的一个好方法是采用混合方法进行系统设计。这涉及到一个由支持微服务包围的中心整体，但只有在有充分理由的情况下才会如此。例如，我们最近在将 NLP 处理集成 到应用程序中时使用了这种方法。

我们已经构建了几个系统，其中核心业务应用程序作为一个整体构建 ( 通常在 Symfony 中 )，由独立的微服务管道处理繁重的数据处理。这不仅允许我们在不影响核心应用程序性能的情况下处理大量数据量，而且如果需要，我们可以在不影响平台的日常 *** 作前提下，将这些组件下线。

理想情况下，你能够清楚地理解规模和未来的开发需求，这对于决定体系结构非常重要。你想快速进入市场吗？您想要支持数百万用户吗？您是否需要处理 大量的数据流 。

尽早做出正确的决定可以增加产品在最短的时间内获得投资回报的机会，而不会妨碍您将来的 探索 。 在后续计划中将组件微服务化通常比最初的 MVP 开发中微服务化更具成本效益。

以上就是关于开发一个猪八戒网站，大约需要多少或者自己请程序员，需要什么程序员，多少程序员能完成全部的内容，包括:开发一个猪八戒网站，大约需要多少或者自己请程序员，需要什么程序员，多少程序员能完成、epoll和select的区别、js里的冒泡事件会增大程序开销，影响性能，应不应该在不需要事件冒泡的事件处理程序里都禁止冒泡等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！