WebAssembly介绍及简单入门
Comments
tags:技术, NodeJS, Javascript
Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually. -- Ending's law JavaScript诞生起到现在已经成为最流行的编程语言(之一),背后正是由Web及相关技术发展所推动的。JS应用正在变得越来越复杂(各种前后端技术、扩展到了手机APP、桌面),但这也暴露出了JS的问题: 语法灵活导致开发大型项目困难 性能在一些场景下不如C/C++等其他语言 一些公司研发了各种框架/语言/工具来尝试补救,比较有名的有微软的TypeScript(强类型,提升代码健壮性)、Google的Dart(新的虚拟机直接运行Dart提升性能),Firefox的asm.js(JS 的子集,引擎针对性能优化)。 那么,WebAssembly,于2015年诞生,2018年发布了1.0版本,被预言为未来的标准,现在已经被4大浏览器(FF,…
从零开始的Microservices服务搭建(三)
Comments
tags:技术, TypeScript, NodeJS
Telling a programmer there's already a library to do Something is like telling a songwriter there's already a song about love. -- Enix Jin 前两篇: 从零开始的Microservices服务搭建(一) 从零开始的Microservices服务搭建(二) 微服务,通过把系统解耦成一个个“微小”的服务解决了大型系统的复杂性问题。然而,在享受分布式系统的好处的同时,我们也会面临分布式系统的复杂性带来的问题。比如,如何跨多个微服务管理分布式事务? 第三步的代码在这里 什么是分布式事务? 当微服务架构将大型系统分解为自封装的小服务时,它同时也破坏了事务。 这意味着大型系统中的本地事务现在会被分布到按顺序调用的多个微服务中。 以下是使用本地事务的客户订单示例: 在上面的客户订单示例中,如果用户将Put Order操作发送到系统,系统将创建一个本地数据库事务。 如果任何步骤失败,则事务回滚。…
从零开始的Microservices服务搭建(二)
Comments
tags:技术, TypeScript, NodeJS
So much complexity in software comes from trying to make one thing do two things. And the rest of the complexity comes from making two things do one thing. -- Enix Jin 上一篇:从零开始的Microservices服务搭建(一) 基于微服务架构为软件开发带来了许多好处,包括小型开发团队、更短的开发周期、语言选择的灵活性、服务可扩展性等。 然而,不幸的是,微服务还引入了分布式系统的许多复杂问题。其中第一个挑战就是如何在微服务架构中实现灵活、安全、有效的身份验证(Authentication)和授权(Authorization)方案。…
从零开始的Microservices服务搭建(一)
Comments
tags:技术, NodeJS, TypeScript, Javascript
Architecture(架构)一词源于建筑学,指建筑物在大尺度上是如何靠内部支撑物相互结合而稳固构造的方式 Architect(架构师)是为满足软件设计目标而在较大尺度上进行整体构思的角色 -- 架构、架构师的定义 建议读本文前先找几本关于Microservice的书阅读一下,我的Slack bookshare里面有几本。 相比设计思想一脉相承的SOA(Service Oriented Architecture),Microservices 是一种把服务分解到更细粒度,松耦合的架构风格。 使用微服务,你的代码将被分解为独立的服务,而这些服务可以用不同的语言开发、部署在不同的地方、作为单独的进程运行。这样的架构风格提供了更高的模块化,使程序更易于开发、测试、部署,最重要的是,更改和维护。(和敏捷开发契合度很高) 市面上有很多微服务的框架,Java的有Spring Cloud和Dubbo(不推荐,缺少很多组件且曾经多年没人维护,使用老旧的RPC),NodeJS也有Seneca和Moleculer可选。不过对于有理想和追求的程序员来说,有什么比自己亲手搭建一个能使自己更了解这种架构呢?(只知道调用API,调整别人的配置有什么意思!) 搭建前的一些技术decision: 微服务的通信全部基于REST(REST服务的搭建不是重点,为了省代码,使用我的小框架@jinyexin/core)…
API设计,从RPC、SOAP、REST到GraphQL(四)
Comments
tags:技术
前两篇: (一)前言&RPC (二)SOAP (三)REST (四)GraphQL(Next?) Talk is cheap. Show me the code. 先放个GraphQL的代码,在这里。(竟然是一个月前的代码了,写文章还是不能拖拉啊) 如同上一篇文章所说,REST是现在API设计的绝对主流思想,但也不是没有缺点的。比如太多的HTTP请求,抓取了过多的信息等。当然,现在有好多各种各样的框架、协议尝试对REST做一些改进。比如HAL、Swagger、OData JSON API。(以上几个都可以花时间浏览下,还是很有启发的) 还有很多小的工程或者项目的内部工具都是为了更加爽快的使用REST而诞生的。我不想一一列举这些工具,这里只是从设计角度,假设我们自己要设计一个基于REST的改进工具,我们会对这个工具有那些要求: 1.最小化HTTP请求数量 每个HTTP请求都是有代价的,握手、延迟、解析甚至如果在移动平台上过多HTTP请求对手机电池的消耗都是必须考虑的。理想情况下,…