如何提升网站架构的可复用性和服务化

[sdsssdss]

如题，我现在要开发一个网站，为了增强重复功能的可复用性，我决定使用Asp.Net WebApi做Http服务，将这些重复功能服务化，并设计了一个初步架构，网站主要说明和架构图如下：
1.网站说明
主要功能：OA、CRM、统计分析
用户群体：内部员工、客户
用户数量：内部800余人、外部1300余客户
性能要求：TPS、HPS、QPS待确定，总体要求用户访问体验不能太慢
2.初步架构图


Q：
　　1. 这样用Asp.Net Web Api做Http服务，实现重复功能服务化是否可行？重复功能服务化是我对该网站做架构设计的主要目的。
　　2. 按照上述网站基本要求，该架构总体上是否可行？本人第一次做架构，基本上属于摸着石头过河。
　　3. 前端和服务端分离后，开发环境中，如何调试和测试呢？
　　4. 前端和服务端分离后，前端与服务端的交互都需要通过网络，对访问速度的影响大吗？有什么技巧可以提升这方面的速度？

　　麻烦大神赐教！！！

[以专业开发人员为伍]

谈不上“可行不可行”，因为你所描述的技术都比较浅显，而且是比较成熟的，因此谈不上可行不可行。只有一些比较深入的议题实际上才会产生一些争议，例如我们的99%以上的服务都是通过websocket，通过独立的windows service来支持，而不是通过web网站服务。只有一个架构不用最浅显的、书本上很常见的架构来实现时，才纠结“可行”问题。如果在浅显的东西上纠结“可行”问题，说明你们的团队以前的技术层面一直不高，做一个好一点的新产品设计比较困难，所以这个重担轮到你来临时承担一下。而你不过是按照最保险、最浅显的思路去设计。 1. 所谓“重复功能服务化”我估计是你老板给你提出的主要任务，所以你反复提及。这里主要是“体会、再体会”，没有别的什么好说的。以前的网站一定是比较垃圾、重复很多。理解了为什么以前的网站比较垃圾，才能体会老板的苦。老板其实是再打你们的原来网站开发主管的脸。所以这谈不上什么“可行”，都走到这一步了，就别问“可行不可行”了。 2. 这个问题是重复1.问题。可见你有多么不能认同领导的意图，而又不得不遵命而为啊。 3. 你的设计图中的"前端“呢？如果你不知道前端在哪儿，说什么”测试“都白搭。 前后端分离，那么后端测试后端的，是深度的测试。而前端既要测试前端的，又要拿出一点精力来测试后端的，但是是接口测试。 4. 还是不知道你所谓的”通过网络“是个什么鬼？！前端用符合现代的框架重构了，比如说把那种”稍微动一下都要刷新整个页面“的设计方式改为web2.0、web3.0潮流的方式了，用户体验快了10倍，那时候还来纠结”通过网络访问后端“吗？可见你看不到新技术，所以提出了这个问题。我也没有办法很具体地回答你，因为我是”看人下菜碟“地回答的，你能提出什么问题就会得到什么样的回答。你如果对于前端有自己的技术，你如果是一个自己动手编程的人，就能提出比较具体的前端设计问题，这样我就能根据你的描述来具体回答一些具体的操作问题。否则，我只能判断你不理解前端，所以第4个问题暂不成立。 我相信你是一个比较成熟的管理人员，所以我可以说一些比较直接了当的回复，你可以看懂。 最后，实际上你贴的图是一个比较常见的图，这种设计的效率是比较低的。例如所谓AppServer在许多系统中并没有，而是直接使用一个商品化的产品（也就是你图中的 Load Balance Server）直接把前端请求映射到 Server。 还有一种形式，就是根本不用什么 Load Balance Server，而是前端（这时候就是一个真正的“富客户端应用”了）最初只是从网站上加载最初的页面，然后首先获得一个“服务器ip列表”，然后快速选择一个访问最快、离自己最近的Server，然后以后就用ip直接与服务器通讯了。这样不但省下了每一次网络访问中的缓慢的 Load Balance、DNS 等等时间，而且可以保证高效即时通讯、双向通讯、断线重连。所以架构简单，不意味着初级，意味着更强。

[以专业开发人员为伍]

你的图上的 AppLayer 整个是个大杂烩，是胡乱拼凑的东西，所以其实这里无法知道什么叫做“前端”。 比如说 AngularJS 是运行在浏览器端的，这时候所谓前端的 MVC 编程是指浏览器端的，那么在 web 服务器上顶多就是放一些等待下载的静态资源文件（例如 js、css文件）。你会因为这些文件放在 web 服务器上，就说 APP Server的组成包括它们吗？那些用来下载js、css、图片等等资源的最简单的web服务器，根本不需要考虑。 好比如说有个初学 QBasic 编程的中学生，写了一个“录入两个整数a和b，程序立刻打印a+b=?"的程序，你说这是服务器程序吗？你的那个图，实际上没有真正画出来 AppServer 真正的作用。（或许如果你真的画出来、也就知道它可以去掉了） 如果别人说你”多访问了一次网络“，这可能是别人对于前端的认识跟你的不同。我想你所谓的前端，还是硬要套用你们以前网站所画的所谓 AppServer 的图，是这个出发点。

[sdsssdss]

p哥亲自回答，实属荣幸。 不过恕我冒昧，你对我的架构图的理解有点小偏差，我明确一下几点内容： 1. APP Layer指应用层，应用层用前端框架AngularJS实现，所以我把简单地把App Layer成为前端。应用层分别用两个web网站来分别实现OA、CRM功能； 2.App Server1、App Server2、Server1、Server2，均指节点，或者说物理服务器； 3.Server1、Server2两套运行不同服务器上同样的东西，一是做负载分流，二是做热备 4.Servie Layer：即我所说的服务端，因为它通过web api对外提供可重用的服务。 5.我们公司之前的系统没有做整体规划，都是单体类型的系统，开发一套是一套，无法实现功能复用，所以利用做新产品的机会正好把产品统一规划一下，以便更快速的对业务需求进行响应，尤其是现在要同时考虑到PC端和移动端。 6.考虑到我们公司也就是800来人的小公司，系统的用户总量不是很大，所以用常规的应用层、服务层、数据层做分层，用轻量级的Web Api做http通信，就足矣，更不用说利用容器技术来实现微服务，所以也就没有显得那么高大上了，适合的才是最好的。即使我们的业务发展迅速，用户规模逐渐增大，在比较长一段时间里都可以利用架构伸缩来实现扩展集群。架构本身就是从从小到大演化出来的，前期适当考虑兼容与扩展就够了，不是吗？ 7.第一个Q从功能可复用的角度来问的；第二个Q从架构常识和技巧角度来问的；第三个Q从应用层和服务层分离到不同节点后的调试与测试方法和技巧的角度来问的；第四个Q是从应用层和服务层分离到不同节点后，相互之间的网络通信速度的角度问的（毕竟应用层和服务层不在一个单体系统里了，必须要用网络来访问了，这个应该很好理解）。 所以，在明确了上述内容之后，p哥能更具体地针对我的四个疑问提出建议吗？多谢！！！

[qq_20078387]

请不要这样，费力不讨好！ 把原来的系统进行重构就可以了