架构
文章平均质量分 90
关注微服务
sp42a
What the web can be
展开
-
分布式领域架构师要掌握的技术
分布式系统无疑是持久的热门话题,但其实如果不是一定有必要,强烈建议不要进入分布式领域,在集中式的情况下很多问题都会简单不少,技术人员千万不要因为外界火热的例如微服务,就把自己的产品的也去做改造,一定要仔细判断是否有必要,不要为了技术而技术,那么在必须分布式的情况下(访问量、存储量或开发人数),一个分布式领域的合格的架构师要掌握哪些技术呢,这篇文章就聊聊这个话题。转载 2023-01-02 00:29:18 · 351 阅读 · 0 评论 -
Dubbo + etcd 搭配
如何配搭 Dubbo + etcd 3 注册中心原创 2022-07-13 11:01:45 · 869 阅读 · 0 评论 -
Dubbo 3 于 Spring MVC 下使用注解配置
Dubbo 是做 RPC 的,基于 Socket + 高性能协议,肯定比 HTTP 调用快多。我当期架构逐渐向分布式靠近,——其实也不是最赶什么微服务的潮流,只是觉得写好的代码,如果不独立,都是依附在某个某个项目中(即“单体”)的话,则很不稳定,有点变化的不好维护。还是独立部署运行比较稳定可用。另外一点好处是,微服务其实可以减少代码重复!你想想看,各个模块哦都独立运行了,变成一个个项目,就是把这模块高度抽象提炼,最大限度复用当期的服务或者组件............原创 2022-07-03 20:04:38 · 732 阅读 · 0 评论 -
SSO 轻量级实现指南(原生 Java 实现):SSO Client 部分
作为统一的认证中心,SSO 中心无疑拥有最根本的用户状态记录,一切皆以 SSO 中心的为准。但每次访问资源的认证工作都要通讯 SSO 中心,性能成本会不会太高呢?对于 SSO 中心服务器的性能也是严重的考验。对此,笔者考虑了以下几个个解决方案。原创 2022-04-28 19:28:21 · 2348 阅读 · 0 评论 -
SSO 轻量级实现指南(原生 Java 实现):SSO Server 部分
OAuth 是当前单点登录(SSO)和用户授权的标准协议——现在就让我们一起动手撸一个 SSO 的实现吧!原创 2022-04-22 23:23:02 · 2482 阅读 · 3 评论 -
高速大量業務的應用架構關鍵
微服務加上Event Sourcing儲存方式,有助實現「高速」的需求,再搭配記憶體計算、請求緩衝和當機接替,就可以打造出不怕爆量的應用架構转载 2022-03-16 11:25:25 · 365 阅读 · 0 评论 -
可配置化 CRUD 服务调研
前期产品已为数据分析提供了较好的数据查询服务,但对于新增、修改和删除暂未实现。故尝试在这次新版本中提供完整的 CRUD 服务,以便提高效率。原创 2021-10-11 14:35:42 · 373 阅读 · 0 评论 -
基于模型管理的调研
引言模型概念本身比较抽象,试举一个例子:现实世界中水、空气……根本组成的是原子,有不同的原子结合各种规则构成了客观多彩的世界。原创 2021-09-10 14:20:27 · 575 阅读 · 0 评论 -
一点一点理解微服务
随着用户数量的增加,我们的项目在一个 Tomcat 容器、一个 MySQL 数据库上倍感吃力,用户抱怨访问响应速度慢,我们在服务器上观察 CPU 占有率飙高,可用内存不足等问题。这种集中式结构如下插图所示,也可称为“单机或单体结构(Monolith)”。原创 2021-06-14 11:32:21 · 574 阅读 · 0 评论 -
OO之美:好代码和坏代码
本节将介绍以下内容:编码的规范面向对象指导引言好的代码,是练出来的。坏的代码,是惯出来的。那么,代码是写给计算机的吗?不是,代码其实是写给人的。Martin Fowler说:任何一个傻瓜都可以写出计算机可以理解的代码。唯有写出人类容易理解的代码,才是优秀程序员。那么,本文要探讨的其实是写出给人看的好代码,不涉及具体的代码技巧,只关注泛化的代码实践,通过一系列条款来过滤应该关注的好代码和坏代码。好代码、坏代码命名很重要,让代码告诉你它自己命名到底有多重要呢?重要到这几乎是很多软件项目成转载 2020-07-27 19:53:00 · 507 阅读 · 2 评论 -
OO之美:面向对象和基于对象
本节将介绍以下内容:基于对象的澄清面向对象的差别引言这是一个常常被问起的话题,对于面向对象(Object-Oriented)我们可能有清晰的概念,对于基于对象(Object-Based)我们可能有模糊的认知,而对于二者一词之差的细节,又有多少概念值得深究呢?关于面向对象的论述,本书第1章“OO的智慧”已经有相对全面的介绍,对于继承、封装和多态这些基本要素,已经有了较为深入浅出的了解,基于如此背景,就先从关注基于对象开始。基于对象所谓基于对象,就是一种对数据类型的抽象,封装一个结构包含了数据转载 2020-07-27 19:43:51 · 332 阅读 · 0 评论 -
OO之美:依赖的哲学
依赖的哲学本节将介绍以下内容:关于依赖和耦合面向抽象编程依赖倒置原则控制反转依赖注入工厂模式Unity框架应用引言“不要调用我们,我们会调用你”是对DIP最形象的诠释。作为5大设计原则之一的DIP原则,有了2.4节“依赖倒置原则”由概念而实例的单纯讨论,还不能全面阐释清楚:什么是依赖倒置?为什么依赖倒置?如何依赖倒置?这几个关键的问题,不单纯地通过DIP而DIP,而是从依赖这个最原始的概念讲起,来了解在面向对象软件设计体系中,关于“关系的处理”,也就是“依赖的哲学”。对,转载 2020-07-27 19:19:02 · 628 阅读 · 0 评论 -
OO 之美:设计的分寸
本节将介绍以下内容:设计的由来浅谈重构设计的分寸引言有了前面两章“OO 大智慧”和“OO 大原则”的铺垫,相信读者已经有了对面向对象的基本认知。而本章将继续深入关于面向对象和设计问题的讨论,挑起设计与架构的话题。在高级语言横行的今天,对于静态语言的设计都源于面向对象思想,重构与设计都基于这些简单的标准。然而,对于设计,还有很多看似“惯常”的法则与经验广泛存在于软件系统中,例如除了经典的 23 种设计模式,还有很多模式之外的模式,按照粒度的大小、系统的特点、规模的大小,而形成的架构规则。对转载 2020-07-27 18:06:40 · 322 阅读 · 0 评论 -
解耦设计手法小结
设计是一个平衡的产物,需要在各个约束条件下(组织目标,业务目标,开发流程,技术能力,学习及维护成本等)不断地进行演进。 我们虽然不提倡做大而全的设计,但会坚持进行基础性设计,以保证我们的设计一直在正确的方向上演进。设计演进的过程既可以是自上而下的,也可以是自下而上的。基本设计原则业界普遍被接受的设计原则不再赘述。这里特别针对基于开源项目的软件,其总体主旋律将是:跟随,扩展,贡献,其中跟随将是一个基本能力,反观深度定制的方式会遭遇越来越多的尴尬。落实在设计上,其最核心的设计原则:隔离自有业务。相较于模块转载 2020-07-27 15:13:22 · 941 阅读 · 0 评论 -
Istio 可以代替 Spring Cloud 吗?
背景过去,我们运维着“能做一切”的大型单体应用程序。 这是一种将产品推向市场的很好的方式,因为刚开始我们也只需要让我们的第一个应用上线。而且我们总是可以回头再来改进它的。部署一个大应用总是比构建和部署多个小块要容易。集中式:分布式:集群分布式和集中式会配合使用。我们在搭建网站的时候,为了及时响应用户的请求,尤其是高并发请求的时候,我们需要搭建分布式集群来处理请求。我们一个服务器的......原创 2020-04-06 15:32:47 · 16756 阅读 · 8 评论 -
通用接口说明
目的为了规范各个接口之间的共性内容,向前端开发者介绍接口用法,特设定该文档。API 接口只提供纯数据输出或者写行为,不包括样式或者模板呈现。接口不限定特定的客户端或服务端,使得 Android/iOS 客户端/HTML5/WindowPhone 和后台 WebService 数据操作均可适用,但某些情况下,会根据客户端提供 UserAgent(简单说,UserAgent 是客户端标识,说明“来者何原创 2015-08-22 19:17:43 · 8154 阅读 · 0 评论 -
Swagger 2(Open API v3.0) Java 文档生成指南(上)
接口文档生成器指的是写好了 API 接口 之后,让前台开放人员(包括不限于 H5 前端、iOS/Android 客户端、小程序等)调用接口时的文档。个人比较主张“代码即文档”,即文档编写在源码之中。先全网选型了一下,发现适合 Java 的有下面几种开源的方案。Swagger,也就是本文的主角,实际情形比较,下面再说apidoc.js,node.js 方案,通过注释写文档,而不是真正代码...原创 2018-09-14 11:47:27 · 10185 阅读 · 7 评论 -
Swagger 2(Open API v3.0) Java 文档生成指南(下)
先介绍网上“搜刮”的资源:Swagger从入门到精通,如何编写基于 OpenAPI 规范的 API 文档,https://legacy.gitbook.com/book/huangwenchao/swagger/details https://blog.csdn.net/lucky373125/article/details/80471525Swagger和OpenAPI https://...原创 2018-09-14 18:49:57 · 8784 阅读 · 0 评论