Browsed by
标签:微服务

微服务,如何拆分服务是精髓 | 技术前沿

微服务,如何拆分服务是精髓 | 技术前沿

閱讀本文約花費: 12 (分鐘)在《云原生基础架构最佳状态,就是没有基础架构》一文中,我们探讨了云原生基础架构的内涵及价值。   本篇我们讨论云原生的又一个重要理念——微服务。   其实之前在《理解了云原生,才能正确迎接云时代的到来》一文中已经简单阐释过微服务,它是区别于过去单一架构产品开发模式的一种新型方式,为的是持续交付这一云原生终极目标。可以说,微服务是云原生的灵魂。既然如此重要,本篇再来详细展开一下,包括什么是微服务、为什么需要微服务、微服务的设计原则等。 从历史发展看微服务起源 2005年,Peter Rodgers博士在云端运算博览会上提出微Web服务(Micro-Web-Service),将程序设计成细粒度的服务,以作为Microsoft下一阶段的软件架构。   2014年,Martin Fowler与James Lewis共同提出了微服务的概念,定义了微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统,每个服务都以一个独立进程的方式运行,每个服务与其他服务之间使用轻量级(通常是HTTP API)通信机制。   Amazon是遇到“微服务”问题最早的公司。当年,Amazon面临着这样一个问题,当团队人数快速增长之后,沟通效率越来越低,如何提高效率,如何减少会议?最终想出来的办法是拆分服务,让各个团队关注不同的模块,让每…

Read More Read More

谁是 左耳朵耗子?

谁是 左耳朵耗子?

閱讀本文約花費: 3 (分鐘)每一位初出茅庐的程序员,都梦想着能遇到一位技术大神,把自己领进编程高手的殿堂。可是现实中,身边并没有那么多大神,即使偶尔遇到,人家也没时间去手把手指导你。 今天小灰给大家介绍一位大神,虽然他的技术非常厉害,但为人却很热情谦逊,很愿意指导行业的新人。这位大神是谁呢?他就是 左耳朵耗子。 左耳朵耗子是谁? 左耳朵耗子,本名陈皓。资深技术专家,骨灰级程序员。MegaEase 创始人, 致力于为企业提供高可用、高并发、高性能的分布式技术产品,同时也提供物联网(IoT)方向的技术产品。 20年技术管理与实战经验,曾在阿里巴巴、亚马逊、汤森路透等公司任职,职业背景是金融和电子商务行业,精通架构和各种大规模的系统开发。十余年受到企业邀请,进行内部培训和分享,涵盖软件团队管理、架构技术、编程语言、操作系统等各方面,并为企业量身定制的咨询或软件开发。 陈皓文章观点鲜明,具有极强的个人风格与特点,言辞犀利,引发读者思考与讨论,鼓励批评与不同的声音。2002 年开始写技术博客,十余年坚持分享对技术的一些见解和心得,得到数十万开发者追随。 左耳朵耗子为我们带来了什么? 陈皓先生花费大量心血,为我们带来一系列精彩的专栏课程分享。课程包含了与技术人或企业切身利益相关的内容,以及更具指导性、更有商业价值的经验。每篇文章都是陈皓的亲身经历和实践总结,非常来之不易。 内容将会…

Read More Read More

MEGAEASE的远程工作文化

MEGAEASE的远程工作文化

閱讀本文約花費: 27 (分鐘)MegaEase 是我创业的公司,主要是想把云计算(PaaS/SaaS层)的那些高可用高并发的分布式技术普及到那需要对技术自主可控的公司,这样就不需要去使用不能自主可控的闭源系统或是大公司的云平台。我于2016年开始成立MegaEase,从早期8个人,直到今天有20来个人,我们从一开始到今天都是在远程工作的公司文化。因为我很喜欢《Rework》这本书,写这本书的公司叫37signal(现名basecamp),这家公司在发《Rework》这本书的时候,整个公司只有16个人,分布在全世界8个城市,这种Geek的公司的文化很吸引我,所以,在我决定创业的时候,我就止不住地想成立这样能够远程工作的公司,于是,远程工作的团队文化就这样成为了MegaEase的基因。下面我会分享一下,我们公司的远程工作文化和其中的一些问题,最后还有一个工作协议。 我们在早期的时候,8个员工来自5个城市,现在的20来个员工来自8个城市2个国家。虽然我们现在使用“共享办公室”,但是本质上,我们的整个文化是远程工作的文化。在2017-2018年度,我们公司产品商业化以来,公司早期的8个工程师在远程工作的状态下成功支持了得到的老罗的跨年演讲活动,以及其它几个客户,一方面验证了用户愿意付费购买我们的产品和服务之后,另一方面也有一些不错的收入,客单价都在百万左右。还记得当时,有几个投…

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

架构设计-谈谈架构

架构设计-谈谈架构

閱讀本文約花費: 32 (分鐘) 本文首先介绍了架构的概念定义,并介绍如何针对当前需求,选择合适的应用架构,希望对您的学习有所帮助。 1、什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这个世界的基础,并用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。 Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个?想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构: 一、系统与子系统 系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能独立完成的工作能力的群体。 子系统:也是由一群关联的个体组成的系统,多半是在更大的系统中的一部分。 二、模块与组件 都是系统的组成部分,从不同角度拆分系统而已。模块是逻辑单元,组件是物理单元。 模块就是从逻辑上将系统分解, 即分而治之, 将复杂问题简单化。模块的粒度可大可小, 可以是系统,几个子系统、某个服务,函数, 类,方法、 功能块等等。 组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。 三、框架与架构 框架是组件实现的规…

Read More Read More

到底什么是数据中台?

到底什么是数据中台?

閱讀本文約花費: 35 (分鐘) 文章中作者主要围绕数据中台是什么?普通企业该不该做数据中台?数据中台会带来怎样的挑战等问题谈了谈自己的看法。 导读:数据中台被誉为大数据的下一站,由阿里兴起,核心思想是数据共享,并在 2018 年因为“腾讯数据中台论”再度成为了人们谈论的焦点。如今似乎人人都在提数据中台,但却不是所有人都清楚数据中台到底意味着什么。数据中台是只有大厂才需要考虑的高大上的概念吗?普通企业该不该做数据中台?数据中台的出现会给现有数据从业者们带来颠覆式的挑战吗?带着上述问题,谈谈他对于数据中台的看法。 数据中台不是大数据平台! 首先它不是一个平台,也不是一个系统,如果有厂商说他们有个数据中台卖给你,对不起,它是个骗子。 要回答数据中台是什么,首先要探讨一下中台到底是什么。虽然没有明确的定义,但是作为理工直男,我们可以先把中台看作是一种中间层。既然是一种中间层,那么中台确实是一种十足技术用语,我们可以完全从技术角度来探讨了。 我们可以应用 Gartner 的 Pace Layer 来理解为什么要有中间层,这样可以更好地理解中台的定位和价值。Pace Layer 里提到,可以按照事物变化的速度来分层,这样可以逐层分析并设计合理的边界与服务。 在数据开发中,核心数据模型的变化是相对缓慢的,同时,对数据进行维护的工作量也非常大;但业务创新的速度、对数据提出的需求的变化,是非常快速…

Read More Read More

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

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

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

Read More Read More

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

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

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

Read More Read More

图解《中台战略》业务中台设计原则

图解《中台战略》业务中台设计原则

閱讀本文約花費: 13 (分鐘) 文章主要介绍了大平台角色之间的松耦合原则、服务生产方依赖原则、服务生产方自身的设计原则、服务生产方提供的接口能力的设计原则、服务生产之间依赖原则等相关方面。 业务中台是一个充满生命力的个体, 它承载业务逻辑、 沉淀业务数据、 产生业务价值,并随着业务不断发展进化。 它的设计遵循如下图所示的若个原则: 业务中台设计原则 中台架构中,有服务的调用方和生产方,按角色关系划分,共有以下四类关系: 1,服务生产方与服务生产方的关系 2,服务生产方与服务消费方之间的关系 3,服务生产方的管理者与服务生产方之间的关系 4,服务生产方与自己之间的关系 这每种关系之间都有对应的设计原则,稍后便看到。 按生产方与消费方之间的调用方式,分三种: A、基于 HTTP/HTTPS 协议的 RESTFul API 调用(最大应用范围) B、基于 Socket/WebSocket 调用 C、基于 SDK 引入调用(受限于技术栈) 其中,A 与 B 的方式是跨语言、跨平台的,应用范围最多;C 的方式受限于系统、语言等因素,B 的应用范围小于 A,但研发成本一般又高于 A。所以 A 这种方式,基于 HTTP/HTTPS 协议的 RESTFul API 规范,应用范围是最广的。 按三种方式能够覆盖的通讯能力表示,如下图所示: A 的通用性最大,B 次之,C 最小。稍后便会看到,基于 …

Read More Read More

学了那么多技术,为何依然成不了架构师

学了那么多技术,为何依然成不了架构师

閱讀本文約花費: 13 (分鐘)在我们的周围存在着很多的全栈工程师,极客达人,他们热爱技术,善于使用各种工具,甚至可以熟练使用多种开发语言,解决各种技术上的问题,但是却无法成为掌控全局的架构师,无法做出最优的架构决策,这是为什么呢? 架构中的哲学 在《道德经》中提到四个字,叫“道、法、术、器”。“道”是天道,“法”是人定的,就是说你该怎么跟着“天道”去做。“法”也有善恶之分。顺应天道的“法”就是善法,相反,违背天道的“法”就是恶法。“术”是指技术层面上的操作方法。“器”是指有型的物质或是有形的工具。 无独有偶,在学习阳明心学的时候,其核心教义也和道家思想一脉相承。 无善无恶是自然之道,有善有恶是人性之法,知善知恶需判别之术,为善去恶用合法之器。他们不是含义上的等价,却是哲学思想层次的完美统一。从道出发,以法为界,以道御术,善于用器。这是一个循序渐进的过程,是解决问题的步骤和方法论。 对于大部分程序员来说,不论是我们参与的工作,还是接受的培训,基本都属于“器”、“术”的范畴。而架构师具备能力:理解业务,全局把控(道),选择合适技术(法),解决关键问题(术),指导研发落地实施(器)。可见成为一名合格的架构师,不仅仅只是具备技术能力就可以完全胜任的,还需要领悟架构之道,架构之法并合理的应用。 何为架构的道、法、术、器呢? 道:架构设计的方向,大道至简。 法:架构设计的原则,有据可依。 术…

Read More Read More

如何构建以应用为中心的“Kubernetes”?

如何构建以应用为中心的“Kubernetes”?

閱讀本文約花費: 23 (分鐘)在上篇文章《上 Kubernetes 到底有什么业务价值?》,主要和大家介绍了上 Kubernetes 有什么业务价值,以及什么是“以应用为中心”的 Kubernetes。本文将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。 如何构建“以应用为中心”的 Kubernetes? 构建这么一个以用户为中心的 Kubernetes,需要做几个层级的事情。 1. 应用层驱动 首先来看最核心的部分,上图中蓝色部分,也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API,比如说 pipeline 就是一个 API,应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。 2. 应用层抽象 所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象,就等同于定义 CRD 和 Controller,所以 Controller 可以叫做应用层的抽象。本身可以是社区里的,比如 Tekton,istio 这些,可以作为你的应用驱动层。这是第一个问题,解决的是抽象的问题。不是特别难。 3. 插件能力管理 很多功能不是 K8s 提供的,内置的 Controller 还是有限的,大部分能力来自于社区或者是自己开发的 …

Read More Read More

云原生:「落地」最重要

云原生:「落地」最重要

閱讀本文約花費: 17 (分鐘)1 云原生这个话题虽然我们谈了很多年了,但到底怎么去理解它,还是需要一段过程。提到云原生,很多人会联想到另一个词:「互联网原住民」,这个词代表了一群出生在互联网时代的人,他们看待世界和思考问题的方式从一开始就和互联网时代以前的人不同。 云原生也是如此。未来我们构建任何系统,不再是原来的那套思考方式,不是把云当成一个工具来使用,而是系统本身就生长于云,并在云上爆发,因此需要我们从根本上转换思考方式,重新定义业务系统。云原生和云计算也不一样,云计算的主角是计算、机器、资源,而云原生的主角是云上延伸出来的应用。 阿里云智能事业群总裁行癫曾经写过一个故事: 在 2004 年那个缺电的夏天,淘宝网全都挤在华星二楼:正是在那里,开始了我的淘宝生涯。我的位置在一个角落里,边上是一堆开着的服务器,吹出的风比七月烈阳下的风更热:因为限电,空调基本上只能看。刚到一个新环境,不知道该做什么,眼睁睁地看着一大群人忙忙碌碌。那时淘宝的节奏是非常快的,我记得小宝有一次说,当时网站如果要改点什么,只要跑到多隆那儿说一下,等他接杯水回到座位打开页面时,需求就已经上线了。 那是 2004 年,基于当时的技术架构,任何需求只要改一下代码,就能够立刻交付。而在现在这样复杂的技术架构下,很难通过简单修改代码实现需求迭代。 但是随着云原生时代的到来,我们又看到了新的机会。为了再现“当年的传说…

Read More Read More

语雀的技术架构演进之路

语雀的技术架构演进之路

閱讀本文約花費: 21 (分鐘)每个技术人心中或多或少都有一个「产品梦」,好的技术需要搭配好的产品,才能让用户爱不释手,尤其是做一款知识服务型产品。 作者何翊宇(花名:不四)是蚂蚁金服体验技术部高级前端技术专家,语雀产品技术负责人。本文从技术架构的视角,回顾了语雀的原型、内部服务和对外商业化的全过程,并对函数计算在语雀架构演进过程中所扮演的角色做了详细的介绍。 语雀是一个专业的云端知识库,用于团队的文档协作。现在已是阿里员工进行文档编写和知识沉淀的标配,并于 2018 年开始对外提供服务。 1 原型阶段 回到故事的开始。 2016 年,语雀孵化自蚂蚁科技,当时,蚂蚁金融云需要一个工具来承载它的文档,负责的技术同学利用业余时间,搭建了这个文档工具。项目的初期,没有任何人员和资源支持,同时也是为了快速验证原型,技术选型上选择了最低成本的方案。 底层服务完全基于体验技术部内部提供的 BaaS 服务和容器托管平台: Object 服务:一个类 MongoDB 的数据存储服务; File 服务:阿里云 OSS 的基础上封装的一个文件存储服务; DockerLab:一个容器托管平台; 这些服务和平台都是基于 Node.js 实现的,专门给内部创新型应用使用,也正是由于有这些降低创新成本的内部服务,才给工程师们提供了更好的创新环境。 语雀的应用层服务端,自然而然的选用了蚂蚁体验技术部开源的 No…

Read More Read More

云上 ARM 实例应用优化之我见

云上 ARM 实例应用优化之我见

閱讀本文約花費: 22 (分鐘) 亚马逊AWS官方博客 发布于:2020 年 8 月 10 日 10:00 ARM 处理器的崛起 过去两个月的科技媒体上关于 ARM 芯片的新闻可谓是高潮迭起,不断的引起人们的关注。 首先是在 5 月 11 日,AWS 宣布了基于自研的 Graviton 2 处理器(使用了 ARM Neoverse N1 核心)的第六代 EC2 实例 – M6g 正式发布。这似乎揭开了云计算市场上 ARM 处理器大规模应用的的序幕。 紧接着,在今年 6 月 23 日的 WWDC 大会上,Apple 公司宣布了一个影响深远的决定: 计划从 2020 年年底开始,Mac 计算机将会从 Intel 芯片过渡到使用基于 ARM 的自研芯片。也许我们要问,ARM 处理器将将会在桌面设备上复制移动设备的成功吗? 第三则新闻是关于高性能计算。6 月 22 日发表的最新的一期 TOP500 榜单上,日本的 Fugaku 系统以 415.5 千万亿次浮点运算的高性能 LINPAC 成绩成为 TOP500 的第一名。而令人惊讶的是这是第一个使用 ARM 处理器的高性能处理系统。 林林总总,即使我们是半导体行业的门外汉也不难得出一个结论 – ARM 处理器不仅仅统治了手机、嵌入式应用这些传统的优势领域,或将在桌面系统、高性能计算尤其是云计算领域扮演越来越重要的角色。 EC2 上的 ARM…

Read More Read More

IT外包公司的真有你想的那么不堪嘛?

IT外包公司的真有你想的那么不堪嘛?

閱讀本文約花費: 6 (分鐘)现在好多小伙伴都问我,我是进小公司比较好,还是进外包公司比较好呢,我就来说说这个问题。 我们首先来说说外包是什么? 外包就是公司从外面请来的帮助你开发软件系统的,类似于古代地主秋忙的时候,请的短工。 通常都是因为公司可能只是临时需要开发一个软件系统,让你过来开发一下,等系统开发完了,可能就让你滚蛋了。 这些公司出钱让我们过来干活,也就是我们口中说的甲方爸爸。 当然,甲方爸爸不可能挨个的找到你,他们通过把自己需要开发的系统,交给一些外包的中间商,然后这些中间商在招人去开发。 说白了,就是甲方公司想省钱省力。 外包公司拿到甲方爸爸的项目,然后由领队的项目经理带人去甲方公司驻厂开发,驻厂开发的通常来说是为了方便和甲方公司的人讨论需求。 当然甲方提需求的人可能是不太懂技术的,会乱提需求。比如之前提出要根据手机壳颜色更改主题颜色的奇葩需求。呵呵 02 一般谁会来当甲方爸爸呢? 当然是有钱的,通常是政府、国企(中国电信、移动、联通)、银行(工农中建交等等)、保险(平安啊,人寿等等),这些甲方爸爸也逐渐的互联网化,项目需求特别的多。 此外,还有一种大家都会忽视的就是大的互联网公司的外包,比如阿里巴巴、华为,你没听错,我们的互联网技术巨头也会找外包。他们一般项目开发多,上线也比较急,公司也是为了节约成本,毕竟一个阿里的研发的工资要比一个外包高好多。 通常会采取一个本部…

Read More Read More

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

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

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

Read More Read More

Scroll Up