展开

关键词

指南

这是一篇综合类指南,试图为你提供一份比较通用的思维框架。当你需要进行时,可以参照它来设计自己的决策树。 如果你的产品在预期生命周期的相当一段时间内需要供多语言用户使用,那么,在初期时,就要把候的国际化能力和质量纳入你的主要考量。访问频度用户的访问频度对前后端的都有很大影响。 对于前端来说,频繁访问的、面向消费者的应用通常会要求更高的流畅度,那么在时,就要择流畅度更高的。 所以,请先客观认识自己的团队,然后再据此进行,千万不要懒于思考,盲从潮流。本身?对本身的考量,主要是代入其它维度之后,看其匹配程度。本身在中可能反而是最不重要的一个维度。 如果只是个数字游戏,那还要你干嘛?话语权驱动这几乎是最糟的,但却屡见不鲜。栈的更迭往往会带来话语权的变化,而这将给公司带来灾难。

47430

我们的

本文是我在中生代群分享的话题《创业一年经历的风雨》中的第一部分《产品架构与》的第二部分。我要谈的是我们产品研发过程中的。开发语言的 我们择的语言是Scala。 数据集的我们还有一个最初的,后来被认为是失败的择。CData服务需要将客户的数据源经过简单的ETL导入到系统中,我们称之为数据集(DataSet)。 前端的前端的则为React + Redux。 在前端方面,我们经历了好几次演变。从CoffeeScript到ES 6,从Reflux到Redux,每次变化都在一定程度上增加了工作量。我在文章《的理想与现实》中讲述的就是这个故事。 结论负责人一个非常重要的能力要求就是——善于做出好的决策。时,并不能一味追求新,也不能以自我为中心,择“我”认为好的

57240
  • 广告
    关闭

    最壕十一月,敢写就有奖

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Android闲聊

    许久没有写博客了,这些时间也一直亲近Android,就聊聊对于一个项目的发展非常重要,个人认为: 决定下限,品味决定上限。 好只能保证做出来的App不烂,品味好了才能将有限的发挥到极致,将所做App提升一个档次。 如果要进一步精准的话,就把那几台特殊的设备号统计出来,加以判断即可(其实不是太必要,因为那么长的非刘海手机被识别成刘海屏,上方留了点背景关系不大)。 版本择再聊聊各种版本择,比如IDE啊,第三方库啊,Android buildVersion啊。 个人偏好:项目稳定性很重要的话,IDE尽量不要预览版(让别人去填坑吧)、各种库也是。 聊得比较休闲,没打草稿,更多是一些个人偏好,如有上的错误,还请指正。

    46430

    OAuth2.0 参考

    今天不会讨论具体的细节,来谈谈 OAuth2.0 的。2. 对 OAuth2.0 的从上面的信息看来, Spring Security 未来依然提供 OAuth2 的 客户端支持 和 资源服务器支持。 所以如果没有授权服务器需求的情况下择 Spring Security 依然是没有问题的,一旦有这个需求我们该如何择?我这里调研了几个开源免费的项目。 3.4 Vertx-auth-oauth2vertx-auth-oauth2 属于 Vert.x 生态,提供了比较完整的 OAuth2.0 实现,而且项目维护比较活跃,唯一的缺点在于有栈的局限性。 总结针对 Java 的一些 OAuth2.0 参考就是上面几个了。不知道你会择哪一个? 我在公众号:Felordcn 发起了一个关于 OAuth2.0 的投票,希望你能够参与。

    63540

    Echo 分析

    其他的常见栈就不说了,MyBatis、Redis 等,本文只讲 Spring Boot 和 Kafka,当然,Kafka 是重中之重,Spring Boot 就简单分析一下优点就完事儿。 为什么择 Spring Boot? 容器,降低了对环境的要求,使得我们可以执行运行项目主程序的 main 函数;4)最重要的,对于开发者来说,那当然是 Spring Boot 不需要编写大量的 XML 配置;5)..........为什么择 为什么择 Kafka再来看看在 Echo 这个项目中,哪些地方使用了消息队列也就是 Kafka:? 点赞、关注、私信等操作都会触发通知,在流量巨大的社交论坛网站中,这个系统通知的需求是非常庞大的,为保证系统的高性能,使用消息队列 Kafka 是个明智的择。

    9910

    如何做好

    在软件开发领域,几乎每天都有新的框架诞生、更新,一些新的概念更是层出不穷,时,难免让人无从抉择。 对于,我个人有以下几点建议:1.有需求,再引入在语言、架构丰富的今天,各类组件很多很多,但并不意味着所有的都应该引入你的项目,倘若单纯为了覆盖全栈或组件而全部引入,这将是一种很不明智的择 拥有强大社区支持的,在后,倘若使用出现疑问、问题、bug等,能够有地方可提、可修复、可深究探讨,毕竟现在的社区都是足够开放的。 处于复杂业务而重构的项目,就需谨慎,往往伴随着一些复杂需求诞生、规模大小的不确定性,不得不考虑可能伴随着一些小修小补或者螺旋式上升的重构,则需便于适配、切换、替换,耦合度低的。 正因为和业务相关,我们能够观察到一些很明显的现象:新往往被早期创业团队或大公司的新兴业务使用;中大公司的核心业务则更倾向于用一些稳定了几年的;一个公司如果长期使用一种,就会倾向于一直使用下去

    16830

    Mock API方案

    当下互联网行业已经从大鱼吃小鱼演变成快鱼吃慢鱼的时代了,从用户需求转化成企业服务的能力,研发效能的高低对用户需求转化速率起到了至关重要的作用,而API服务的研发效能是当中非常重要的一环。 建议RAP1 长达3年+ 未更新维护,RAP2 长达1年+未更新维护,开源项目一档超过半年未迭代更新,择就需要慎重,同时对比阿里对待开源的态度,不能商用大部分是KPI考核项目如果是JAVA项目,可以采用 YAPI + Swagger 的方案,无缝集成,其它类的项目也可以单独使用YAPIYAPI -> RAP2 -> Swagger -> RAP1安装(推荐方式)使用官方提供的 yapi-cli 部署

    8630

    Realm初体验

    . * * 也可以使用@RealmClass注解来生命数据模,比如: * * @RealmClass public class User implements RealmModel { ... } * dog.deleteFromRealm(); 移除所有符合条件的查询结果 results.deleteAllFromRealm(); }});以上就是Realm的CRUD基本用法,第一次使用确实被惊艳了,很简单易用啊,符合的一个要求 它有没有一些我们不知道的坑,必须有啊,具体看下以下这篇文章:说说 Realm 在 Android 上的坑指明了realm有以下缺点:线程的限制(realm对象只能被创建它的线程中访问,不能随意切换)数据类( 其实还有增加包大小的问题(可以通过split abi来减少包大小)总结本篇文章,只是粗略了介绍了Realm的用法,还需要更加深入去使用才能决定是否使用到项目中,在中,除了简单易用还要考虑是否适合自己的场景

    14810

    优秀的(摘

    优秀的(摘)1.1. 缓存redis因为是单线程,不适合高耗时操作,对数据量比较大的缓存还是memcached比较合适1.2. 监控系统zabbix 在主机数量不多时是非常好的择prometheus 最流行的配合grafana进行前端展示influxdata的influxdb和telegrafelkb使用es存储的工具链(elasticsearch 需要建立数据仓库搜索方面solr和elasticsearch,后者实时性更好列式存储方面,基于Hadoop的hbase,使用最广泛tidb国产新贵,兼容mysql协议时序数据库方面,opentsdb用在超大监控系统多些 CICD支持持续集成和虚拟化 jenkins是打包发布首,idea的公司还写了一个TeamCity也可参考gitlab搭建的git服务器中,gitlab CI也可以用1.11.

    21542

    微服务之路

    本文以笔者个人经历讲述关于微服务方面的和相关知识点。微服务模式的项目从初建到上线部署应用,每一个环节都会涉及到相当多的细节(上线后的性能调优更需要)。 本文着重介绍一套微服务搭建流程中面临的一些,战略性的方案及相关的简要介绍,不做每一项的深入说明。   微服务方便融合最新。 微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面组件混合。 微服务能够即时被要求扩展。 微服务能部署中低端配置的服务器上。 易于和第三方应用系统集成。 微服务 前几年较为火的微服务有阿里的Dubbo方案。后面又出现了Spring体系下的微服务方案。本文主要介绍Spring体系下的微服务方案。 具体搭建一套微服务可参考如下方案: 不同的择应用的场景不同: 网关:若整个公司业务都基于java开发,可以直接使用Spring Gateway做网关。

    27840

    开发Hybrid App的

    my.oschina.netwxqdoit一、前言如果我们把Hybrid App理解为运行在android或者ios以及其他移动终端设备上的应用,也可以叫做H5 APP,这种开发应用的模式结合web开发与 Native开发的部分,通常也被称为混合开发模式。 三种方式的比较(图片来自网络)三、Hybrid App开发的核心毫无疑问,webview是Hybrid App开发的核心。webview可以简单的理解为一个浏览器。 Hybrid App在只有一套美UI的情况下应当如何处理以适配不同的机呢?媒体查询、百分比,或是直接使用web端常用的单位px、em、rem以及vh、vw,都是常用的适配方案。 angular、react相对而言比较重,vue显得轻量一些,当开发大SPA应用时,前两者是不错的择,而vue完整的工具链以及活跃的社区也适应绝大部分的开发场景。九、jQuery还用吗?

    1.2K30

    区块浏览器

    87280

    微服务架构

    开发框架微服务框架Spring Cloud Spring Cloud alibaba : Spring Cloud是一系列框架的有序集合。 配置中心Nacos:阿里巴巴重点开源项目、可同时作为注册中心配置中心,简化栈、有完善管理界面、Java开发、二次开发方便、社区活跃、CP模式,还在不断更新迭代。 服务发现Nacos :阿里巴巴重点开源项目、可同时作为注册中心配置中心,简化栈、有完善管理界面、Java开发、二次开发方便、社区活跃、CP模式,还在不断更新迭代。 监控Prometheus:功能较为全面的开源监控系统,CNCF栈、社区活跃Grafana:Grafana是一个开源的度量分析与可视化套件。 Web服务器Tomcat:Tomcat 服务器是一个免费的开放源代码的Web 应用服务器,属于轻量级应用服务器,在中小系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首

    39630

    DCOS之监控(中)

    苏研 DCOS 今天我们本节介绍DCOS监控模块的,主要介绍DCOS监控等,接下来,请阅读:DCOS之监控这一章节我们来比较监控容器的常用工具。 Prometheus 特点是高维度数据模,时间序列是通过一个度量值名字和一套键值对识别。灵活的查询语言允许查询和绘制数据。 它采用了先进的度量标准类像汇总(summaries),从指定时间跨度的总数构建比率或者是在任何异常的时候报警并且没有任何依赖,中断期间使它成为一个可靠的系统进行调试。 像多维度的数据模,来实现数据聚合、分组、过滤,不单单是 Prometheus。OpenTSDB 和 InfluxDB 这些时间序列数据库和系统监控工具的结合,让系统监控这件事情变得更加的多元。 1、难易程度 :容易2、监控指标的详细度:较好4、告警能力: 较好5、监控目标多样性:较好6、成本:免费择 Docker 的监控相比其他的数据库、系统、中间件监控,要复杂一些。

    11210

    Kubernetes Ingress 控制器的

    又该如何结合自身的择合适的方案呢?在本文中,腾讯云中间件核心研发工程师厉辉将为你介绍如何进行 Kubernates Ingress 控制器的。 Ingress 原则 既然发现了 Nginx Ingress 有很多问题,那是不是考虑择其他开源的、更好用的 Ingress? 但是每个开发人员所擅长的栈不同,所以适合的 Ingress 也会不一样。 那么问题来了,我们如何择一个更加好用的 Ingress 呢? 或者缩小点范围,熟悉 Nginx 或 OpenResty 的开发人员,应该择哪一个 Ingress 呢? 下面来介绍一下我对 Ingress 控制器的一些经验。 ? 2.基础软件 前面有提到,每个人擅长的平台不一样,所以择自己更加熟悉的 HTTP 网关也显得至关重要。比如 Nginx、HAProxy、Envoy 或者是 Golang 原生网关。

    37310

    系列 - Tair&Redis对比

    2)支持big_list(list无长度限制)(3)支持创建schema,cmd query 支持的总数据量 1000+instance scale out,理论上总数据量无限制 适宜的读写比 存内存, 均适合 存内存,均适合 支持多引擎,适宜各种比例的读写。 实际使用情况基本是0个备份) 0~N个数据slave备份(实际使用情况基本是0个备份) (1)多机数据冗余(2)断电数据不丢失,重放redo log(3)数据完整性crc校验(防止磁盘损坏) 数据可靠性 用户可是否开启持久化 用户可是否开启持久化 强,有持久存储,一般不会丢失数据 多副本 支持(副本平时可读) 支持(副本平时可读) 支持(副本平时不提供读写) 副本一致性 弱 弱 可根据业务需求配置强一致弱一致 持久化 支持

    1.4K20

    HBase漫谈 | HBase准则

    聊一聊 NoSQLNoSQL(Not only SQL)数据库,可以理解为区别于关系数据库如mysql、oracle等的非关系数据库。 NoSQL必须要在一致性、可用性与分区容错性之间做出取舍,目前而言,几乎所有的NoSQL都是在保有分区容错性的基础上择一致性或可用性,例如HBase就是牺牲了部分可用性换取了完全的一致性,与HBase 然而,事务支持、关联特性,甚至于SQL查询,这些却是NoSQL的短板,也决定了NoSQL尚且取代不了关系数据库。? 关于我们在实际生产过程中满足哪些条件的时候可以择HBase作为底层存储,这里给出几点建议:1、数据量规模非常庞大一般而言,单表数据量如果只有百万级或者更少,不是非常建议使用HBase而应该考虑关系数据库是否能够满足需求

    76110

    创业公司原则

    在重点去谈创业公司如何做之前,咱们先来看看的一般性原则。 的通用原则择并不像看上去那么美好,没有择和择太多都会让人痛苦,尤其是在当今大爆炸和开源项目满天飞的今天,“择麻痹”应该是最让决策者头痛的毛病。 要缓解它,就必须建立起我们自己的标准,或者说原则。在经历了这些年多次“艰难的抉择”之后,我总结出了适合我个人的原则。原则1:能否简化开发任务? 路线,是在进行时必须要面对的问题,尽可能地择符合公司路线的或工具,这样有助于工作的快速推进。 总结领导日常工作的一部分,但就不同阶段的公司而言,的标准并非一成不变的。针对公司不同阶段的关注的重点,本文简单谈及了相应的标准和原则,同时结合自身给出了相应的实例。

    74720

    注册中心分析

    本文是对微服务中,注册中心的的一些思考和分析,部分比如etcd,本人没有在生产环境使用过,所以部分结论的得出,是在阅读了大量的资料后得出的结论。 如eureka,在实际中,很多小项目,其实就是一个单点的eureka做注册中心,也没发生过什么生产事故,但就调研和储备而言,我们不能只考虑理想的场景,了解各种的优缺点,用的时候,起码知道这个的短板和可能带来的一些问题 文章是站在调研consul时,看其他产品的短板来看的,每个产品都有自己的长短版,如果短板对自己业务无负面影响,或者影响可接受,那时就问题不大。

    48340

    项目中怎样做

    很少成为我的难题。不是因为这方面我多有方法,而通常是很少有择。 在做的场景下基本有以下四个维度:维度一从系统构成上有两种:第一种,有之前的老系统,需要重构第二种,从零开始建的服务维度二从稳定性要求上有三种:第一种,现在没有什么业务量,将来估计也不会有什么增长 公司有没有同类或者可以登高类比(登高类比是指先找相似度最高的,找不到在逐渐扩大范围)的,那些项目遇到过哪些坑或者问题,是否和架构或者项有关。 重构老系统,现在对稳定性要求很高建议尽量和之前保持一致,以便于和之前的逻辑尽量一致。避免踩到特殊需求导致的特殊逻辑等坑。 这时候要考虑的主要是的成熟度。这个成熟度包含业界本身的成熟度和团队成员对的熟练度。对于这种类,还有几句忠告:不要特立独行,要合群!使用成熟的!使用成熟的成熟功能!

    4010

    扫码关注云+社区

    领取腾讯云代金券