Browsed by
标签:支付

恒大造车的荒诞故事

恒大造车的荒诞故事

閱讀本文約花費: 33 (分鐘)2020 年农历新年前不久,广州东南 60 多公里外的恒大汽车南沙基地,工作人员已为重要人物的到来准备多日。 这个临近珠江出海口的基地占地 126 万平米,相当于特斯拉上海工厂的 1.5 倍。开工一年多,H 型排列的三间巨大厂房尚未完工,只有最右侧的总装车间封顶,园区里大部分还是泥地。 要客要参观的总装车间设备尚不齐全,也没完成调试。整个基地只有三四十个工人,根本没法站满车间里的数百工位。 更大的问题是到视察前夜,恒大汽车的研发团队都不知道这个基地未来究竟生产什么车型。 但视察当日,从南沙港快速路驶下的要客车队没有经过一片狼藉。从进入园区开始,到视察目的地总装车间,车队都行驶在混凝土路面上。基地工程师和施工人员提前冲洗路面、扫清积水、在两侧摆上鲜花。来不及处理的烂泥地和建筑垃圾,则被一人多高的盆栽挡住。 打开车门,许家印伴随地方领导一行走入车间,看到的基本是工业 4.0 概念宣传片的画面:德国西门子的传送带将白色车壳往前运输,特斯拉工厂同款的橙色库卡机械臂灵活地转动,对车身射出黄色的电焊弧。更远一些,身着白色工服的工人站在完工的汽车边上,拧着扳手。 有限的人手都被安排在参观路线周边的工位。平时不在产线工作的基地工程师那天也穿着工服,站在工位里。如果参观者走远一些,就会看到厂房更多区域空空荡荡,没有工人。 但现场的…

Read More Read More

最常用的Java框架或者开源项目有哪些?

最常用的Java框架或者开源项目有哪些?

閱讀本文約花費: 19 (分鐘)系统设计 微服务/分布式 基础框架 Spring Boot [1] :Spring Boot 可以轻松创建独立的生产级基于 Spring 的应用程序,内置 web 服务器让你可以像运行普通 Java 程序一样运行项目。另外,大部分 Spring Boot 项目只需要少量的配置即可,这有别于 Spring 的重配置。 spring-cloud-alibaba[2] : Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 Spring Cloud Alibaba Sentinel[3] :A lightweight powerful flow control component enabling reliability and monitoring for microservices. (轻量级的流量控制、熔断降级 Java 库)。 Dubbo[4] :Apache Dubbo 是一个基于 Java 的高性能开源 RPC 框架。 Nacos[5] :Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮…

Read More Read More

平安付公司壹钱包APP出故障 男子获利千万被判11年

平安付公司壹钱包APP出故障 男子获利千万被判11年

閱讀本文約花費: 11 (分鐘) 原标题:金融理财APP出故障 男子获利千万判11年 叶榅飞一审判决书。受访者供图叶榅飞一审判决书。受访者供图   律师吴绍平回忆,会面时,叶榅飞始终在问:欠钱还了就好了,真的要被判刑?   叶榅飞是福建人,在上海生活多年。去年6月,在使用一款名为“壹钱包”的金融理财软件时,叶榅飞发现,存入的钱被退回银行卡内,但软件上的账户余额却相应增加。此后8天,叶榅飞利用这一故障,前后转账超过350次,套现1125万元。   “壹钱包”平台运营方报警后,叶榅飞被警方拘留。近日,叶榅飞的辩护律师吴绍平收到该案一审判决,法院以盗窃罪判处叶榅飞有期徒刑11年,并处罚金50万元。叶榅飞妻子昨日接受新京报记者采访时表示,丈夫并非主动侵入系统盗取资金,而是利用产品漏洞牟利,并据此提出上诉。   发现漏洞后转账350余次   8天时间里,叶榅飞转了350多次账,每转一次,就意味着得到一笔“意外之财”。   2015年6月16日,叶榅飞下载了理财软件“壹钱包”,并注册激活。当年9月10日,叶榅飞用妻子黄丽丽的证件和手机号码,以黄丽丽的名义,办理平安银行(16.070, 0.50, 3.21%)“花漾卡”,并与“壹钱包”账户关联,用于后者的转账和消费。   “壹钱包”客户端由平安付科技服务有限公司(下称平安付公司)推出,花漾卡则是平安付公司与平安银行…

Read More Read More

软件架构万字漫谈:业务架构、应用架构与云基础架构

软件架构万字漫谈:业务架构、应用架构与云基础架构

閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用,了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际…

Read More Read More

设计详解:电商业务中台如何实现可视、可配、可复用?

设计详解:电商业务中台如何实现可视、可配、可复用?

閱讀本文約花費: 23 (分鐘) 本文从常见的中台架构出发,对中台产品设计如何实现可视、可配、可复用这个问题展开了详细解析,与大家分享。 建设中台最直接的目的一般是为了帮助企业快速且低成本的创新,这就要求了中台必须降低使用方的学习成本,能把各个业务进行集中管理以及需要有较低的学习门槛,简单来讲就是:可视化、配置化、低代码。中台产品设计如何实现可视、可配、可复用?本文作者从常见的中台架构出发,对这个问题展开了详细解析,与大家分享。 中台在这两年是一个非常火的概念,其出现的目的只有一个:帮助企业快速且低成本的进行创新。 二十年前,中国的互联网刚刚起步,在线交易一片荒芜,商品信息极难通过在线进行展示,更别论在线交易;十年前,中国互联网蓬勃发展,以阿里、京东为代表的企业实现了在线交易基础设施的搭建,大部分的消费则能够在网上查找商品并进行交易; 而如今,互联网日益向着成为水电煤的趋势发展,各种模式、形态的电商不断涌现,昨天刚出现蘑菇街、小红书,今天就有有赞、拼多多;昨天刚大力吹捧微博、公众号的自媒体营销,今天又有小程序的出现。 在这个极其不确定的时代里,任何一家企业都害怕错失机会,不断出现的新鲜事物,让企业创新的成本越来越高,如何能够通过尽量少的成本,而不失尝试新鲜事物的机会,成为企业经营中遇到的难题之一。 一、常见的中台架构 在聊中台的时候,我们一定需要聊一聊软件架构,软件架构是系统发展到…

Read More Read More

印度政府宣布禁用118款中国App软件

印度政府宣布禁用118款中国App软件

閱讀本文約花費: 3 (分鐘)  据海外网援引新德里电视台2日报道,印度政府宣布禁用118款中国APP软件。印度电子和信息技术部声称,这些手机应用程序已根据《信息技术法》被禁止,理由是“他们从事损害印度主权完整、国防、国家安全和公共秩序的活动”。   据印度ANI新闻网消息,印度印度电子和信息技术部(MEIT)9月2日发布公告,宣称禁用118款“涉嫌参与危害印度主权与(领土)完整、印度国防、国家安全和公共秩序活动”的中国App,其中包括《绝地求生》手游(PUBG MOBILE LITE)、企业微信(WeChat Work)、微信读书(WeChat reading)、名片识别软件“名片全能王”(CamCard)、百度(Baidu)、照片编辑软件“Cut Cut”、视讯应用“VooV”、新浪新闻(sina news)、手机淘宝(mobile taobao)、优酷(youku)、支付宝(Alipay)等。   印度《金融快报》提到,此前6月29日,印度政府宣布禁用59款中国App,一个月后再次宣布禁用47款中国App。至此,印度政府已禁用224款中国App。   自从今年6月中印边境发生冲突以来,印度打压中国企业的动作一直不断。6月,印度政府还声称出于“安全”考虑,禁止包括TikTok、微信、微博在内的59款中国应用,认为这些应用从事的活动有损印度主权、国防、国家安全和公共秩序。然而,在…

Read More Read More

经济内循环是什么?

经济内循环是什么?

閱讀本文約花費: 28 (分鐘)聊这个话题前,我们得先聊一个关键问题: 到底什么是“过剩”? 因为现在的问题,是产能太强,生产出来的东西卖不出去,产能天天过剩。产能过剩导致了一系列问题,甚至资本主义世界周期性的危机,本质也是周期性过剩。这可能和大部分人的直觉反差很大,因为大家一般觉得东西不够才会危机,生产太多怎么会危机呢? 1 躲不开的“过剩” 首先大家得分清楚一个关键问题,这也是我经常引用的一句话: 你希望有五个老婆,这叫需要; 但是你只养得起一个,这叫“有效需求”。 同理,老王想要苹果全家桶,BBA各来一辆,两个超模保姆,大平层,天天米其林,各种潮鞋,天天逛两趟SKP。 但是上边说的这些老王都买不起,只能买得起小米手机,那他的需求就只有小米手机。在市场经济的话语体系里,如果“买不起”,那你就不是人。 产能也一样,看着似乎是天量的,但如果大家都买不起,或者因为其他原因不需要这些玩意,那就是产能过剩。 不过问题变得更加奇怪了,能生产出来,怎么就卖不出去呢? 有很多种原因,最关键的是下边这个。我们捋一遍在资本主义世界里的一个标准生产流程,大家就知道啥原因了。 假设地球是一个村,里边有资本家黄四郎和一堆村民。黄四郎有个厂子,他雇佣村民们生产自行车、脸盆和房子等生活必需品,将来卖给村民。 如果这些商品价值100万,这时候就有个分配问题,如果黄四郎自己拿20万,给员工们分80万,合理吧。 …

Read More Read More

苏宁高时效、高并发秒杀业务中台的设计与实现

苏宁高时效、高并发秒杀业务中台的设计与实现

閱讀本文約花費: 20 (分鐘) 文章主要介绍了苏宁架构设计背景,苏宁的架构设计以及系统多活部署与单机房宕机场景下的降级方案 设计背景 对于苏宁易购主站而言,正常的用户购物流程囊括选品、下单、库存扣减、付款、订单状态更新、物流履约等。但是在电商业务中往往会涉及到对某些热点商品的秒杀场景。相比于正常购物流程,秒杀场景具有时效性高、并发量大、瞬时业务量极高的业务特性,往往会出现显著的分布式一致性问题。正常的业务系统不能很好地应对瞬时高并发的业务需求,因此就需要针对于秒杀场景进行相应的架构优化,抑或是设计专门用于秒杀的中台业务系统。 就秒杀业务而言,系统在瞬时会达到极高的并发量,如果与其它业务耦合,那么势必会对其它业务造成风险,因此基于安全性考虑和业务隔离原则,秒杀系统在设计上应该与其它系统充分解耦,单独部署。本文将讨论在苏宁现有的技术架构和中台组件的基础上,如何去实现一个通用型秒杀业务中台。 架构设计 1. 系统前端与负载层设计 图一:前端与负载层设计 鉴于秒杀业务本身的高并发特性,对用户请求进行前端分流是必不可少的一步。在系统上游就对部分用户请求进行处理,可以避免海量请求对后端服务器产生过大压力。因为用户往往在秒杀前几分钟就开始点击下单按钮,因此在秒杀开始前可以使用静态资源页面,用户请求由 CDN 直接响应,不必到达后端服务器。 此外,由于秒杀业务的高时效性特征,下单窗口基本集中在秒…

Read More Read More

《微服务架构设计模式》之二:服务的拆分策略

《微服务架构设计模式》之二:服务的拆分策略

閱讀本文約花費: 67 (分鐘) 2.1 微服务架构到底是什么第1章描述了微服务架构的关键思想是如何进行功能分解。你可以将应用程序构建为一组服务,而不是开发一个大型的单体应用程序。一方面,将微服务架构描述为一种功能分解是有用的。但另一方面,它留下了几个未解决的问题,包括:微服务架构如何与更广泛的软件架构概念相结合?什么是服务?服务的规模有多重要?为了回答这些问题,我们需要退后一步,看看软件架构的含义。软件的架构是一种抽象的结构,它由软件的各个组成部分和这些部分之间的依赖关系构成。正如你将在本节中看到的,软件的架构是多维的,因此有多种方法可以对其进行描述。架构很重要的原因是它决定了应用程序的质量属性或能力。传统上,架构的目标是可扩展性、可靠性和安全性。但是今天,该架构能够快速安全地交付软件,这一点非常重要。你将了解微服务架构是一种架构风格,可为应用程序提供更高的可维护性、可测试性和可部署性。我将通过描述软件架构的概念及其重要性来开始本节。接下来,我将讨论架构风格的概念。然后我将微服务架构定义为特定的架构风格。让我们从理解软件架构的概念开始。2.1.1 软件架构是什么,为什么它如此重要架构显然很重要。至少有两个专门讨论该主题的会议:Oreilly的软件架构会议和SATURN会议。许多开发人员的目标是成为一名架构师。但什么是架构,为什么它如此重要?为了回答这个问题,我首先定义术语软件架构…

Read More Read More

如何搭建支付中台系统?

如何搭建支付中台系统?

閱讀本文約花費: 10 (分鐘) 编辑推荐:本文主要讲解了什么是中台呢?中台能解决什么问题,如何去搭建适合公司的中台系统?支付中台如何落地? 什么是中台 中台其实最早是起源于军事领域,在二战时期的美军在各个战场上,看起来有打不完的弹药、耗不完的燃料、充足的食品补给、及时准确的情报……但其资源却在万里之遥的美国本土,这一切是如何做到的呢? 就是依靠庞大的中台体系,支持到世界各战场。前方战场上的一名士兵,平均就有12名人员支持,在战场-基地-本土形成前、中、后台的效率系统。 国内互联网最早实行中台战略的就是阿里。 由于阿里涉及的业务线非常多,在没有中台之前都是每个业务自己去做一套系统,但是每个业务系统都有相同的模块,例如订单系统、支付系统、商户系统、短信系统等。因此就导致各个业务线重复造轮子的现象,业务端不仅需要对业务模块进行优化和升级,同时也需要维护这些基础支撑服务。 用一句话概括:中台就是将所有业务的公共模块抽象出来,单独创建一个中台系统统一对这些公共模块进行维护,统一输出服务提供业务方使用,让业务方能够集中全力发展业务。 中台解决什么问题 理解了中台的概念,那么就需要思考对于互联网公司,中台系统的搭建能够解决什么问题呢? 可以解决你的996问题 中台是独立于业务系统而又服务于业务系统的存在,业务系统的前台和后台是关联存在的,但是中台的定位就是出于整个公司层面,要服务于多条业务线。…

Read More Read More

蚂蚁金服大规模微服务架构下的Service Mesh探索之路

蚂蚁金服大规模微服务架构下的Service Mesh探索之路

閱讀本文約花費: 44 (分鐘)前言 今天给大家带来的内容叫做Service Mesh探索之路,但是在前面加了一个定语:大规模微服务架构下。之所以加上这个词,是因为我们这个体系是在蚂蚁金服这样一个大的架构下进行的,蚂蚁金服的体量大家可以想象,所以这个探索会带有一个非常隆重的色彩:对性能/规模/高可用等方面的思考。 在深圳的GIAC大会,我们同事披露了这个正在开发中的 Service Mesh产品,我们现在暂时命名为 SOFA Mesh。我们目前的产品都在 SOFA品牌下,比如 SOFA RPC,SOFA Boot等。今天我们详细介绍 SOFA Mesh这个单独产品,上次大会只是简单披露,也就是给大家介绍说我们有这样一个产品,而我今天的内容是把这个产品详细展开。 一、技术选型 先上来一堆要求,刚才我们提到过的,因为是大规模,而蚂蚁金服的体量,大家可以想象到的。实际上在性能,稳定性上,我们的衡量标准,我们考虑的基石,都是以蚂蚁金服这样的一个规模来考虑的。 在这样一个规模下,我们会涉及到一些跟其他公司不太一样的地方,比如说:我们在性能的考量上会比较重一些。因为如果性能不高的话,可能没法支撑我们这样一个规模。在考虑性能的时候,就有另外一层考量:架构和性能之间的这个权衡和取舍是要非常谨慎的。性能要求不太高的情况下,架构可能的选择,和需要比较高性能的情况下,可能会有完全不一样的取舍。稳定性就不…

Read More Read More

我是如何参与硅谷顶级开源项目并赚得 2500 美金

我是如何参与硅谷顶级开源项目并赚得 2500 美金

閱讀本文約花費: 6 (分鐘)初识MinIO 三年前,公司要做一个分布式存储的选型,当时考察了Ceph、FastDFS、GlusterFS和MinIO,经过慎重考虑,最终我们选型了MinIO。在选型MinIO的过程中,我也通过github加入到这个开源组织。在17年的时候,MinIO还远没现在这么完善,软件有bug,特性不全,连中文文档也没有,而且也不出名,github上只有几千个star。为了方便公司使用,我就打算翻译MinIO的使用文档,不过转念一想,要玩就玩大点,既然没有中文官方文档,为何我不能来写中文官方文档。于是我就在社区中找到MinIO的创始人Anand Babu Periasamy,和他说,我看MinIO没有中文官方文档,要不我来翻译如何。他欣然接受,并安排MinIO的开发人员Kannappan与我对接。 翻译MinIO中文官方文档 以前没参与过大型的github开源项目,为了能让这个工作顺利进行,我了解了一下github开源项目的合作机制,开源社区的文化、习惯,避免被别人说STFW和RTFM。 翻译工作对我来说倒没什么难的,过程也很顺畅,大概花了一两天把核心文档翻译完了,也顺利合并到主干。这时候MinIO的一个开发人员找到我,和我说: [ ](https://imgchr.com/i/aRaKxJ) 其实我和第一次听他这么说,我心里是拒绝的,我这好好的参与开源,怎么…

Read More Read More

分布式事务问题的几种方案

分布式事务问题的几种方案

閱讀本文約花費: 8 (分鐘)分布式事务的实现主要有以下 5 种方案: XA 方案 TCC 方案 本地消息表 可靠消息最终一致性方案 最大努力通知方案 两阶段提交方案/XA方案 所谓的 XA 方案,即:两阶段提交,有一个事务管理器的概念,负责协调多个数据库(资源管理器)的事务,事务管理器先问问各个数据库你准备好了吗?如果每个数据库都回复 ok,那么就正式提交事务,在各个数据库上执行操作;如果任何其中一个数据库回答不 ok,那么就回滚事务。 这种分布式事务方案,比较适合单块应用里,跨多个库的分布式事务,而且因为严重依赖于数据库层面来搞定复杂的事务,效率很低,绝对不适合高并发的场景。如果要玩儿,那么基于 Spring+JTA 就可以搞定,自己随便搜个 demo 看看就知道了。 对于这个方案,一般来说某个系统内部如果出现跨多个库的这么一个操作,是不合规的。我可以给大家介绍一下, 现在微服务,一个大的系统分成几十个甚至几百个服务。一般来说,我们的规定和规范,是要求每个服务只能操作自己对应的一个数据库。 如果你要操作别的服务对应的库,不允许直连别的服务的库,违反微服务架构的规范,你随便交叉胡乱访问,几百个服务的话,全体乱套,这样的一套服务是没法管理的,没法治理的,可能会出现数据被别人改错,自己的库被别人写挂等情况。 如果你要操作别人的服务的库,你必须是通过调用别的服务的接口来实现,绝对不允许…

Read More Read More

再有人问你分布式事务,把这篇扔给他

再有人问你分布式事务,把这篇扔给他

閱讀本文約花費: 24 (分鐘)前言 不知道你是否遇到过这样的情况,去小卖铺买东西,付了钱,但是店主因为处理了一些其他事,居然忘记你付了钱,又叫你重新付。又或者在网上购物明明已经扣款,但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务,你去小卖铺买东西,那就是一手交钱一手交货。有了事务,你去网上购物,扣款即产生订单交易。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交,只要其中任一操作执行失败,都将导致整个事务的回滚。简单地说,事务提供一种“要么什么都不做,要么做全套(All or Nothing)”机制。 数据库本地事务 ACID 说到数据库事务就不得不说,数据库事务中的四大特性,ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行,要么要是发不出货,就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成,那么…

Read More Read More

常用的分布式事务解决方案

常用的分布式事务解决方案

閱讀本文約花費: 46 (分鐘)众所周知,数据库能实现本地事务,也就是在同一个数据库中,你可以允许一组操作要么全都正确执行,要么全都不执行。这里特别强调了本地事务,也就是目前的数据库只能支持同一个数据库中的事务。但现在的系统往往采用微服务架构,业务系统拥有独立的数据库,因此就出现了跨多个数据库的事务需求,这种事务即为“分布式事务”。那么在目前数据库不支持跨库事务的情况下,我们应该如何实现分布式事务呢?本文首先会为大家梳理分布式事务的基本概念和理论基础,然后介绍几种目前常用的分布式事务解决方案。废话不多说,那就开始吧~ 什么是事务? 事务由一组操作构成,我们希望这组操作能够全部正确执行,如果这一组操作中的任意一个步骤发生错误,那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作,要么全都正确执行,要么全都不要执行。 事务的四大特性 ACID 说到事务,就不得不提一下事务著名的四大特性。 原子性 原子性要求,事务是一个不可分割的执行单元,事务中的所有操作要么全都执行,要么全都不执行。 一致性 一致性要求,事务在开始前和结束后,数据库的完整性约束没有被破坏。 隔离性 事务的执行是相互独立的,它们不会相互干扰,一个事务不会看到另一个正在运行过程中的事务的数据。 持久性 持久性要求,一个事务完成之后,事务的执行结果必须是持久化保存的。即使数据库发生崩溃,在数据库恢复后事务提交的结果…

Read More Read More

Scroll Up