如题,我现在要开发一个网站,为了增强重复功能的可复用性,我决定使用Asp.Net WebApi做Http服务,将这些重复功能服务化,并设计了一个初步架构,网站主要说明和架构图如下:
1.网站说明
2.初步架构图
Q:
1. 这样用Asp.Net Web Api做Http服务,实现重复功能服务化是否可行?重复功能服务化是我对该网站做架构设计的主要目的。
2. 按照上述网站基本要求,该架构总体上是否可行?本人第一次做架构,基本上属于摸着石头过河。
3. 前端和服务端分离后,开发环境中,如何调试和测试呢?
4. 前端和服务端分离后,前端与服务端的交互都需要通过网络,对访问速度的影响大吗?有什么技巧可以提升这方面的速度?
麻烦大神赐教!!!
挺好的,足以满足这么点人的服务啦,还避免了单点故障。
用户数量在加2个0,这个架构都没问题。
在加几个0就可以把service layer里面的service单独拆分。加上服务发现,路由,治理
3:做好完善的单元测试,使用test工具对api进行系统测试。
4:服务器部署上在同一个机柜或者内网环境。网络环境不复杂,网络传输就是几毫秒的事情。
多谢。
所以这个架构从设计的合规性和满足功能可复用和服务化的角度来说都是符合要求的,对吧?
那么对于这种应用层和服务层分离到不同节点的情况,都可以用单元测试来完成测试,都是各测各的,各调各的,根据需要再合并到一起来做集成测试对吧?
我准备用阿里云的ECS、Redis、和负债均衡,不知道访问速度会怎样?
还有,cache和session放在App Layer没问题吧
@weegoood: aliyun 还行啦,整个园子都是在阿里云上面嘛,我自己也有几台机器在。用下来感觉还可以
测试方面,开发这边单元测试。如果有测试,或者自己做:完整的接口测试,和接口回归测试比较好。这样接口升级呀什么的。可以保证兼容性
严格意义上来说session在分布式里面不是一个好东西。少用。因为lvs的问题。session不能在app layer。不然因为各种原因,原来服务的a机器,后面换到b机器。那不是session没有了么。少量数据可以考虑放到类似redis,memcache里面去
@calvinK: ok,明白了,昨天已经把代码基础框架搭起来了,非常感谢