首页
学习
活动
专区
工具
TVP
发布

物流IT圈

专栏作者
280
文章
506430
阅读量
97
订阅数
产品经理在说的"项目管理"到底是什么?
众所周知,产品经理跟项目经理的岗位职责是有区别的,但在部分公司,产品经理在进行规划产品的同时,偶尔也要担负部分项目经理的工作,阿境结合市面上项目管理的流程及自己所处公司的情况,讲讲产品经理如何进行项目管理。
物流IT圈
2020-07-07
9650
盘点7款顶级 PHP Web 框架
2019年,PHP 代表超文本预处理器(Hypertext Pre-processor)是非常流行的 Web 服务端编程语言,小编今天就来和大家一起盘点7款顶级的 PHP 框架。
物流IT圈
2020-03-16
4.6K0
Spring Web 应用的最大败笔
开发人员在使用Spring应用是非常擅长谈论依赖注入的好处。不幸的是,他们不是那么真的利用它的好处,如单一职责原则,分离关注原则。如果我们一起来看看大部分Spring的Web应用程序,常见的错误的设计如下: 1.领域模型对象用来存储应用的数据(当作DTO使用),领域模型是贫血模型这样的反模式。 2.服务层每个实体有一个服务。 问题是这样很普遍,错误在哪里呢? Spring的web应用程序之所以这样是因为他们做事物的方式一直都是这样做的,老习惯难改,特别是如果他们是高级开发人员或软件架构师,这些人捍卫这样做的论据之一是:我们的应用程序遵循关注分离的原则,因为它已经被分为若干层,每个层有自己的特定职责。 1. Web层负责处理用户输入,并返回正确的响应返回给用户。 web层与服务层通信。 2.服务层作为一个事务边界。它也负责授权和包含我们的应用程序的业务逻辑。服务层管理的域模型对象,并与其他服务和存储库层进行通信。 3.存储库/数据访问层负责与所使用的数据的存储进行通信。 分离关注(Soc)是分离计算机程序为不同的部分,每个部分有一个关注聚焦,一个典型的Spring Web应用在一定程度上遵循这一原则,但现实是,该应用程序有一个整体的服务层,它有太多的责任。更具体地,服务层有两个主要问题: 1.在服务层发现业务逻辑 业务逻辑被分散在各个服务层。如果我们需要检查一个业务规则是如何实现的,我们必须先找到它。这可能并不容易。此外,如果相同的业务规则需要在多个服务类,问题是,规则需要从一个服务到另一个简单地复制。这将导致维护的噩梦。 2.每个领域模型一个服务 这完全违反了单一职责原则,它被定义为如下:单一职责原则指出,每一个类都应该有一个责任,责任应该由类完全封装。其所有的服务应该狭义与责任相一致。(不应将原属于领域模型的行为方法等划放在服务中实现,对象不但有属性还有行为) 服务类有很多依赖,以及大量的循环依赖。更像网络紧密耦合和单片服务。这使得很难理解,维护和重用。这听起来有点苛刻,但一个Spring的web应用的服务层往往是最容易出问题的部分。幸运的是,所有的希望都不会丢失。 1. 我们必须将我们的应用程序的业务逻辑从服务层迁移到领域模型类中。 举个例子:假设我是一个服务类,你是一个域模型对象。如果我让你从屋顶上跳下来,你会喜欢我这样的决定吗?(跳下来会摔伤,自己没有脑子或被洗脑,变成僵尸,只听从执行,不思考自己的安全,这就是贫血模型的问题) 将业务逻辑从服务层迁移到域模型类有下面三个优势: (1)我们的代码将以逻辑方式切割,服务层只要关注应用逻辑,而我们的领域模型关注业务逻辑。 (2)业务逻辑只存在一个地方,容易发现修改。 (3)服务层的源代码是清洁的,不包含任何复制粘贴代码 2. 将每个实体服务切割为单一目标的更小的服务。 比如,有一个单一服务类,提供对人员和用户账户的CRUD操作,我们应该将它分为两个独立的服务类: 第一个是对人员的提供CRUD操作 第二个是提供与用户账户相关的操作。 好处:每个服务类中有一个逻辑组职责。每个服务类的依赖较少,这意味着他们不再是紧耦合的源头。他们是较小的和松耦合的组件。服务类更容易理解,维护和重用。 这两个简单的步骤将帮助我们使得我们的应用程序架构更干净,有助于同行开发商提高生产力和幸福。
物流IT圈
2019-12-11
3460
用啤酒和乐高解释什么是API
API是我们一直都在使用的东西。尽管他们无处不在,但许多人 - 甚至是技术人员对API是什么以及工作方式都有一个非常模糊的理解。说真的,你可以请你的同事快速解释API,他们一般告诉你:“API代表应用程序编程接口。它是一个能让软件应用程序彼此通信的接口......“,如果这样解释的话,大多数人真的无法真正地理解它。 对于前端人员或其他业务人员,API是一个黑盒子,我们如何解释给他们听呢? API中“A”是应用App的意思 这个A就是严重依赖于上下文的,需要根据具体的使用案例确定,“应用程序App”实际上可以
物流IT圈
2019-11-23
1.1K0
【产品设计】基于业务中台的多租户权限管理设计方案
在设计后台系统(如:CRM、EPR、EHR、电商管理后台等)时,权限管理是必不可少的功能,绝大部分的后台系统都是处理企业业务流程的,会涉及到多个部门的协同合作,必然需要对每个能够使用系统的用户进行权限管理。
物流IT圈
2019-10-16
3.3K1
什么是四层应用架构?
  随着移动应用的不断普及,传统后端三层架构已经不能再满足需要了,这种三层架构我们通常称为monolithic(巨石 整体的 铁板一块的)的架构。
物流IT圈
2019-08-23
3K0
传统企业微服务落地大法(2)-必须经历的第一阶段
如果你真的要做微服务,那你一定逃不掉这个阶段。(如果你连这个都没到,那就别瞎想了哈)
物流IT圈
2019-07-16
4460
传统SpringMVC到Springboot迁移之路
最近在把公司的老项目迁移到springboot,遇到了很多坑,包括jar包的升级,代码重构,以及全方位的测试。具体过程参照了简书上的一篇文章。
物流IT圈
2019-07-16
4.2K0
10个有关RESTful API良好设计的最佳实践
  Web API已经在最近几年变成重要的话题,一个干净的API设计对于后端系统是非常重要的。
物流IT圈
2019-07-16
6180
多线程让可扩展性走进了死胡同
这是一篇来自Python世界的文章,但是对整个编程领域还是适用的,多线程虽然让我们处理请求更快,但是也是有天花板的,绿色(微线程micro-thread)线程之类才是解决方案。 多线程软件开发解决了大量的问题,尤其是以网络为中心的应用程序,这些程序需要严苛的性能快速响应用户。不幸的是,多线程并不足以解决大规模并发性的问题。 解决这些问题需要改变编程模型,使用异步事件和基于回调机制。在Druva,我们创建了一个基于python库的名为Dhaga来解决大规模并发,而编程模型不需要重大改变。 软件开发人员生活在一个并发的世界。线程如今是一等公民,今天在开发过程中,特别是当您的应用程序执行密集的网络运营,如同Druva一样的inSync系统(网络安全同步产品)。多线程帮助网络操作的编程代码流变得简单和顺序。当我们的应用程序需要增强的性能或改善其可伸缩性,我们可以增加线程的数量。 但是当需要成千上万规模的并发请求,线程是不够的。 我们发现多线程使用有以下缺点: 1. inSync系统客户端需要大量的文件通过网络RPC调用备份到服务器。开发人员加快速度的典型方法是使用线程。但多线程带来的性能却增加内存和CPU的使用成本;开发人员需要在速度和线程数之间保持一个平衡。 2.我们的服务器需要处理inSync系统与成千上万的客户之间并发连接和通知。为了有效地处理连接,我们使用线程来处理请求。但inSync系统客户的不断增加也意味着我们不得不继续增加线程的数量,从而消耗大量服务器的内存和CPU。 3.我们的Web服务器需要处理成千上万的平行的HTTP请求。大部分工作是在接收和发送的数据网络套接字并将其传给inSync系统的后端。导致大多数的线程等待网络操作。导致C10K问题,当有成千上万的同步请求到Web服务器,为每个请求生成一个线程是相当不可扩展的(Scale)。 异步框架的限制 许多异步框架,包括 Twisted扭曲、Tornado龙卷风和asyncore可以帮助开发人员远离使用线程的流行的方式。这些框架依赖非阻塞套接字和回调机制(类似Node.js)。如果我们按原样使用这些框架,我们Druva代码的主要部分必须重构。这不是我们想要做的事。重构代码会增加开发和测试周期,从而阻止我们达到规模要求。鉴于产品的多个部分需要大规模,我们每个人将不得不重构他们——因此增加一倍或两倍的努力。 为了避免改变如此多的代码,我们不得不离开直接使用现有的框架。幸运的是,我们发现一些有用的工具。 因为我们想要控制在网络I / O的代码执行,我们需要一种将一个线程划分为微线程micro-thread的方法。我们发现greenlets。它提供一种非隐式的微线程调度,称为co-routine协程。换句话说。当你想控制你的代码运行时它非常有用。您可以构建自定义计划的微线程,因为你可以控制greenlets什么时候yield暂停。这对我们来说是完美的,因为它给了我们完全控制我们的代码的调度。 Tornado是一个用Python编写的简单的、非阻塞的Web服务器框架,旨在处理成千上万的异步请求。我们使用它的核心组件,IOLoop IOStream。IOLoop是一个非阻塞套接字I / O事件循环;它使用epoll(在Linux上)或队列(BSD和Mac OS X),如果他们是可用的,否则选择()(在Windows上)。IOStream提供方便包装等非阻塞套接字读和写。我们委托所有套接字操作给Tornado,然后使用回调触发代码操作完成(banq注:非常类似Node.js机制)。 这是一个好的开始,但我们需要更多。如果我们在我们的代码中直接用上面的模块,我们大量的RPC代码将不得不改变,通过greenlets调度RPC,确保greenlets不要阻塞(如果greenlets堵塞,它会堵塞整个线程和其他全部),处理来自tornado的回调功能。 我们需要一个抽象来管理和安排greenlets 以避免让它被外部调用堵塞,这个抽象能够超越线程达到大规模可扩展。这个抽象是Dhaga,它能让应用代码流编程起来像传统同步顺序,但是执行是异步的。 Dhaga(来自印地语,这意味着线程)是我们抽象的一个轻量级线程的执行框架。Dhaga类是来源于greenlet,使用堆栈切换在一个操作系统线程中执行多个代码流。一个操作系统的线程中使用协作调度执行多个dhagas。每当一段dhaga等待时(主要是等待一个RPC调用返回),它yield控制权给父一级(也就是说,是创建它的操作系统级别线程的执行上下文)。然后父一级会调度安排的另一个dhaga准备运行。RPC调用将传递给tornado web服务器异步写入Socket,然后在其返回时注册一个回调,当这个RPC返回时,正在等待的dhaga将被添加到可运行队列中,然后后被父线程拾起。(banq注:类似node.js原理) 我们可以使用Dhaga代替线程
物流IT圈
2019-07-16
8090
没有更多了
社区活动
RAG七天入门训练营
鹅厂大牛手把手带你上手实战
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档