分布式开发记录1 粗暴的设计及粗暴采用的技术

目前遇到的问题.

因为当前的应用是一个单网站应用.

1>水平扩展新功能.现有系统可以增加新功能,但是不方便布署.成本很高.晚上0点更新一次.

2>垂直深入业务.这点是目前最大的问题.例如,考勤1.0->考勤1.1,要同时兼容当前使用的多个客户,又要满足特殊客户,还要快速,目前框架相当于无法处理.多版本共存.成本很高.

3>灰度发布.有一些业务需要发布在线上,才能完整测试.目前框架无法处理.

4>负载均衡.可以处理.成本太高.某些业务在特殊的时间段会突发性的增长.不可能为了这些时间段,单独增加服务器.

似采用微服务方案:

1>服务怎么划分?还未想好.

2>前端的路由和后端内部api怎么关联起来?1:N?还未想好.

理论与研究

http://www.open-open.com/lib/view/open1436089902667.html

原文:

https://www.nginx.com/blog/building-microservices-inter-process-communication/

使用api 网关?

似采用ocelot [api网关]

http://www.cnblogs.com/pjjwpc/p/6485465.html

预期解决的问题

1> 2> 3> 4>

引入消息队列,实现更好高并发和高性能,

异步业务处理部分 消息队列:

似采用EQueue

http://www.cnblogs.com/netfocus/category/598000.html

存在的问题,

如,下单->库存->支付,以往是一个请求,一致性很强.同步反馈到客户端,客户点击支付,->支付成功.

但是改变为异步的时候,下单->库存->支付,不能马上反馈到客户端,需要客户端轮询,前端开发需要注意修改方案,怎么简化.反应性编程.

如何在前端处理异步业务,像是同步调用的方式.反应性编程.

http,如何来处理异步业务处理,反应式处理Promise 机制

客户端,因为是.net  Reactive Extensions(Rx) 

原文地址:https://www.cnblogs.com/forhell/p/6755702.html