• 分类:【系统架构
  • 浏览【161】
  • 评论【0】
  • 更新【2020-7-17 19:49:05】

前后端分离 近几年比较流行的web项目开发架构是前后端分离,前后端分离架构在系统稳定性方面非常有优势,其中一点优势主要体现在用户感知上,即使服务端发生错误也不会展现在视图层,一般情况下用户是可以继续浏览网页,不会很突兀的显示这样的信息: 502 bad gateway 在接口发生错误时虽然可能会获取不到一些数据,但是在用户体验上比直接显示502错误要好。 部署也相对安全和方便。 前后端分离架构虽好,但不是”银弹”,不是所有网站都能使用前后端分离架构来做。 服务端渲染 至于分不分离都有诸多的优缺点,可根据实际场景选择,本文要说的是不分离情况下文章开始所提到的问题——难看的502,500错误。

阅读全文
  • 分类:【系统架构
  • 浏览【541】
  • 评论【0】
  • 更新【2020-5-10 11:44:34】

前言 接上篇《说道说道前后端分离》今天再次对前端现状作一次分析(吐槽)。 再次引用一句《穷查理宝典》中的理论: 在手里拿着锤子的人看来,所有的东西都会是钉子。 因为有锤子的关系,遇到任何问题,都会先想如何用锤子解决。久而久之,陷入了一种思维定式。任何工具带来便利的同时,也带来了局限性。而这往往是用锤子的人很难看到的。 事出有因 这种现状在开发圈内决不少见,不仅限于前端。本文只说说前端的现状,原因是笔者最近在工作中遇到一个棘手的问题:性能优化。 最近接手了多个现有的前端项目,是公司比较核心的移动端官网,作为门户网站访问量和用户量都比较大,但是随着项目的迭代出现了性能问题,页面加载速度在W

阅读全文
  • 分类:【系统架构
  • 浏览【315】
  • 评论【0】
  • 更新【2020-1-10 16:48:58】

由于“中台”概念的推动,关心业务架构的读者越来越多,很多企业也对实施“中台”、“中台”方法论趋之若鹜。历史总是相似的,之前无论 SOA、微服务、DDD,还是敏捷开发、双模开发等热门技术概念出现时,都曾经给大家燃起“捷径”的希望。 然而,最终还是证明了软件领域没有“银弹”,很多时候,反倒是应了北欧的一句民谚:捷径是迷路的最快方法。 架构没有捷径,无论从架构的设计、架构的落地还是架构的学习方面来讲,都是如此。 1.架构设计没有捷径 架构设计如同求医问诊,必须对症下药。盲目相信任何已有架构设计成果都是很危险且极不负责任的。每个人的身体都各有特点,企业也是如此,而企业级转型、企业级工程是对企业现有能力

阅读全文
  • 分类:【系统架构
  • 浏览【399】
  • 评论【0】
  • 更新【2019-12-13 12:00:37】

最近为公司官网重构搭建项目,把遇到的问题总结一下。此处的“商业”并没有多神秘,说的有点夸张而已,不过是为了区分公司项目与个人项目罢了。在这之前,我自己搭建过的网站也不下于10个,其中有个人网站也有公司网站,那时候搭建的网站也能上线运行,也没有过多的条件限制,所以不会有什么纠结的地方。 所以搭建一个网站并不复杂,复杂的是让其满足很多要求。有业务需求,有领导喜好,有同事对技术的接受度。业务说网站要支持SEO,支持IE浏览器,领导说我们要前后端分离,同事说我想使用主流新技术。最后经过几轮商讨下来自然是业务第一,领导第二,同事第三的优先级进行选择了。 要支持SEO和IE浏览器,只能是服务端渲染,可选的

阅读全文
  • 分类:【系统架构
  • 浏览【859】
  • 评论【0】
  • 更新【2019-2-25 15:45:05】

一、什么是服务发现 二、consul 简介 三、consul的几个概念 四、安装 Consul 五、运行 Consul Agent 六、集群成员 七、停止 Agent 八、注册服务 九、Consul 集群 十、健康检查 十一、KV Data 十二、Consul Web UI 十三、Docker下安装consul 作者:菲宇 来源:CSDN 原文:https://blog.csdn.net/bbwangj/article/details/81116505

阅读全文
  • 分类:【系统架构
  • 浏览【720】
  • 评论【0】
  • 更新【2019-2-25 11:09:12】

【编者的话】本文对比了Zookeeper、etcd和Consul三种服务发现工具,探讨了最佳的服务发现解决方案,仅供参考。 如果使用预定义的端口,服务越多,发生冲突的可能性越大,毕竟,不可能有两个服务监听同一个端口。管理一个拥挤的比方说被几百个服务所使用的所有端口的列表,本身就是一个挑战,添加到该列表后,这些服务需要的数据库和数量会日益增多。因此我们应该部署无需指定端口的服务,并且让Docker为我们分配一个随机的端口。唯一的问题是我们需要发现端口号,并且让别人知道。 当我们开始在一个分布式系统上部署服务到其中一台服务器上时,事情会变得更加复杂,我们可以选择预先定义哪台服务器运行哪个服务的方

阅读全文
  • 分类:【系统架构
  • 浏览【766】
  • 评论【0】
  • 更新【2019-2-20 10:40:41】

同一台服务器上部署了两个功能差不多的服务,但是内存占比差距有点大。 go占14.7M nodejs占122.2M

阅读全文
  • 分类:【系统架构
  • 浏览【1664】
  • 评论【0】
  • 更新【2018-10-13 17:38:35】

gRPC是谷歌开发的跨语言(C, C++, Python, PHP, Nodejs, C#, Objective-C、Golang、Java)RPC框架,跨语言是指可以使用gRPC进行个语言之间的通信,例如:PHP可以对java进行远程调用。 在系统架构中,我们会把多个系统公共的模块拆分出来做成单独的服务,可以提供RESTful接口,也可以为了低延迟快速响应而提供RPC接口。如果选择的是gRPC,上线后发现多个系统都请求这个RPC服务提供者,而且流量很大的时候负载过高导致崩溃。为了降低负载和提高可用性,理所当然的要做集群,用nginx作为代理服务器,幸运的是nginx版本为1.13及以上支持了

阅读全文
  • 分类:【系统架构
  • 浏览【1012】
  • 评论【0】
  • 更新【2018-6-12 21:34:47】

“过早的优化是万恶之源”,这句话或多或少在哪听过,不过为什么优化也会带来问题,恐怕只有经历过的人才能理解其中的意义。 关于程序优化,产品优化这些词在开发工作中一定有经历过。某位程序员做事一丝不苟,对程序开发特别注重性能问题,花大量时间来优化某段代码。某位产品在提出需求的时候总是有一些目前用不到的功能,说是为了方便将来扩展。 那么实际工作中这种优化到底起到了什么作用?个人认为弊多于利。 问题一:过早引入新技术 甲同学在做一个员工日常工作内容列表的接口时,认为该接口会产生性能问题,将来数据增多的时候会有性能瓶颈,于是利用了某项缓存技术,觉得缓存一定比直接查数据库速度快,于是就引入了缓存数据库。把数

阅读全文
  • 分类:【系统架构
  • 浏览【881】
  • 评论【0】
  • 更新【2018-6-10 21:54:23】

消息队列(MQ)在系统架构中发挥了重要作用,其主要作用有系统解耦,流量削峰,异步消息存储,分布式系统最终一致性等。 本文介绍的是消息系统中消息发布者和订阅者间参数如何约定和传递?实际应用场景中,一种消息的发布者和订阅者都有可能是多个,也就是多对多的关系,这样就形成了消息参数传递的复杂性,就算一开始参数有约定,大家都按照最初约定来开发,但不免开发过程中各端需求变化带来的修改。例如最开始为了实现系统解耦而引进了消息队列,此时消息参与者较少,只有一个发布者和一个订阅者,这种情况最简单(其实最简单还是直接调接口),双方简单约定了需要传递的参数。 { userId:123, userName:&qu

阅读全文