应用架构之择

有什么样架构，就有什么样建筑!

前者的架构用来盖厂房，后者的架构是建摩天大厦

特不正经就今天和大家讨论软件应用的大厦如何构建？

I、单体架构 or 微服务架构

微服务已经风靡神州，已然是万人迷

那么，微服务这个万人迷长得很美吗？

这个万人迷有以下特点：

易于开发、理解和更新；

比单体应用启动快；易于扩展，提供高并发服务；

局部修改很容易部署，有利于持续集成和持续交付；

故障隔离，一个服务出现问题不会影响整个应用；

不会受限于任何技术栈,每一个微服务可以用不同技术开发。

那么微服务架构导致那些问题？

效率问题；

微服务之间的调用，有网络延迟和连接开销，效率下降

安全的复杂性；

服务调用，势必需要认证和校验调用者的身份，需要授权管理

部署和运维管理头大；

一个应用拆分为几十上百个微服务，部署和监控是个头大的问题

单体应用呢？

所有微服务架构导致的问题，都是单体应用的优点

既然谈到了应用架构，应用寄生的基础架构我们是绕不开的

有人说serverless架构可以不考虑基础架构，呵呵，这个以后再谈

大家来看看应用架构和基础架构的演变过程...

客官，你看到了吗？

应用架构和基础架构是共生关系，相互促进，相互依赖

单体应用架构物理硬件时代

C/S应用架构虚拟机时代

多层应用架构云计算时代

微服务架构 容器编排时代

那么什么情况下用单体架构（或多层架构），什么情况下用微服务架构？

特不正经的小结：

产品还是项目？

项目大部分开发工作是一次性的，而产品需要随着版本的升级不停迭代

项目通常都是固定范围和时间，而产品并没有固定的边界

产品的开发可以充分利用微服务的优势，而项目，尤其是小型项目可能得不偿失！

简单应用还是复杂应用？

微服务固然有很多优点，但微服务带来的挑战也是巨大的

复杂应用采用微服务可以充分利用微服务的并行，隔离等优点

但简单应用引入微服务架构，带来额外的巨大开销，反而有可能增加项目的成本！

基础架构准备就绪了吗？

与微服务对应的基础架构是云计算平台和容器编排，将基础架构最大化的自动化，用代码处理基础架构 Infrastructure as Code（IaC）

在基础架构没有就绪的情况下，引入微服务将是相当痛苦的过程。

团队运维能力是强还是弱？

使用微服务，一些技术债务势必从开发转到运维。

从管理数量有限的物理服务器或者虚机，到数量庞大的容器

从为数不多的应用，到数量庞大，交互复杂的微服务

以前传统的监控，运维工具，在微服务环境下，会有相当的不同。

因此，你最好有一个一 流的开发运维团队，一流，看到了吗？

开发模式是什么？

开发模式通常也会对架构的选择有重大的影响

采用DevOps的团队与微服务配合较为顺畅，而瀑布式开发（waterfall）模式则采用微服务架构比较困难！

II、服务总线 or API网关 or 服务网格

先看看服务总线，到API网关，到服务网格的发展历程

应用之间的交互太复杂了，SOA流行了，服务总线ESB出现了..

后来，对外部的合作增加了，需要将内部的能力转化为外部

API 管理出现了...

一度，甚至上升到“API经济”的高度（呵呵，特不正经很佩服砖家的造词能力）

API网关解决了API安全性，API的负载均衡，API的发布、版本控制等等...

API网关在移动应用开发方面，确实简化了开发

随后，应用开发的模式产生了变化，微服务让API 网关更加流行了..

微服务的数量越来越多，微服务也分层了...

Core Services：原子Service

Composite Services： 组合的Service

API Service/Edge Services: 通过API 网关对外提供服务的service

随着微服务的发展，作为中心节点的API网关无法胜任了...

更为彻底的分布式诞生了...

服务网格化的需求越来越强烈，Service Mesh出世了...

微服务之间交互带来的安全性，负载，容错，可视化问题，将交由服务网格(Service Mesh)来解决（需要了解详情，请参照特不正经写的“微服务之三兄弟”，有详细介绍）

特不正经的小结：

ESB和API Gateway并非竞争关系

ESB是单体应用时代的产物，它是SOA的实现，为内部应用交互提供标准化

而API Gateway的产生是对外交互和合作的产物，将企业的能力开放出来，为外部合作和内部业务创新提供服务。

内部交互ESB和外部交互API Gateway

各有其用，各得其所！

ESB和ServiceMesh与架构相关

企业中单体应用或者外购商品化软件为主的情况下，应用之间依然需要交互，因此ESB是最好的选择。

而在微服务架构下，服务的治理将是Service Mesh的天下！

III、RPC or REST API

我们这个社会，一样东西一旦成为时髦，疯狂不可避免...

建议大家读一读《乌合之众》

RESTful API一火，大家争先恐后采用RESTful 来编写API,地球人已经无法阻挡了

唯恐自己成了Out Man...

RESTful API的魅力在哪里？

从面向实用的角度来看，REST架构风格可以为Web开发者带来多项好处：

开发简单性

采用REST架构风格，对于开发、测试简单。可以充分利用大量HTTP开发库、Web功能测试/性能测试工具。

开发只要以资源为中心，定义POST/DELETE/GET/PUT，没有更多的

运维简单

可以充分利用HTTP缓存、HTTP代理服务器、CDN、防火墙。不必在买额外的设备，额外的学习成本

可伸缩性

充分利用好通信链各个位置的HTTP缓存组件，可以带来更好的可伸缩性。其实很多时候，在Web前端做性能优化，产生的效果不亚于仅仅在服务器端做性能优化，但是HTTP协议层面的缓存常常被一些资深的架构师完全忽略掉。

松耦合

对于越来越强调松耦合的今天，不仅在设计时应该关注，而且应该放在最优先位置，而且对互联网API尤其重要。

既然REST那么好，为什么作为互联网巨头的Facebook推出的Thrift，Google推出的gRPC都基于RPC呢？

问题在哪里？

特不正经列举了REST的六大罪状：

Use HTTP/1.x; Separate TCP Connection per request

Text on the wire; Not performance efficient

Harder API evolution

Not Domain-Specific

Not strongly-typed

Lack of streaming capabilities

那么RPC的优点在哪里？

特不正经以Google gRPC为例：

High performance, open-source universal RPCframework

A Cloud Native Computing Foundation(CNCF) project

Uses Protocol Buffers as the IDL

HTTP/2 for transport

Bi-Directional streaming

RPC is efficient, domain-specific and strongly-typed

Works across languages and platforms

再说说ProtoBuf：

language-neutral, platform-neutral, extensiblemechanism for serialising structured data

IDL - Describe once and generate interfaces for multiplelanguages

Structure of the Request and Response

Binary format for network transmission

Supports multiple languages

REST与RPC的差别在于：

REST支持抽象的工具是资源，RPC支持抽象的工具是过程。REST风格的架构建模是以资源(名词)为核心的，RPC风格的架构建模是以动词为核心的。

RPC中没有统一接口的概念。不同的API，接口设计风格可以完全不同。RPC也不支持操作语义对于中间组件的可见性。

RPC使用二进制传输，响应的内容中只包含消息本身。REST使用了超文本，可以实现更大粒度的交互。

RPC风格也常常会带来客户端与服务器端的紧耦合。支持统一接口+超文本驱动的REST风格，可以达到最小的耦合度。

什么时候选择RPC，什么时候选择REST？

特不正经的小结：

性能考虑

gRPC和REST的性能相差非常大，以google自身的API为例

下图是性能比较：

在性能要求为主导的场景下，优先选用RPC

对外交互考虑

对外交互时，涉及API标准化的问题

REST风格先天具备（当然，也很傻瓜！）

而且在HTTP上，运维方便，开发上一目了然，成为Web API的事实标准

对外开放API，REST API是必然之选。

合作共存考虑

RPC和REST是可以混用的，必要时，可以结合使用，对外部用REST，内部交互使用gRPC。

gRPC gateway提供了REST API和gRPC的转换

IV、H5 vs Natvie vs React Native

这里要谈的是移动开发的架构选型：

1、HTML5（简称H5）

H5也就是Web App的方案。

优点：

天生可移植“Write Once, Run Everywhere”，不管你是Android还是iOS，都可以用一套代码搞定。

缺点：

很明显因为浏览器性能的原因，很难带来很好的用户体验。

所以说，H5的主要适用场景还是在于作为对业务在移动端的入口补足，或者是作为用户轻量、低频使用的场景。

2. 原生应用(Native)

原生应用的开发是个矛盾结合体，让人又爱又恨。

优点：

你可以将它发挥到极致，使用新特性、实现炫酷的效果。能够方便地添加动画效果，调用底层硬件。

缺点：

跨平台性几乎为零，除了资源外几乎没有可重用的东西，iOS和Android完全不同。

需要对不同的平台搭配不同的开发人员。

设计得满足相应平台的设计规范，这不仅是对开发的考验，也是对UX的考验。

如果真的对App的质量有很高的要求，讲究动画效果、追求用户体验的应用，还是建议分平台单独设计，并且都使用原生的技术方案来实现。

3. 混合方案Hybird

Hybird是一种兼顾Native与H5的开发模式，但根据实现的不同，还可以再细分为两种实现方案：

在Native App中使用WebView加载远端Web资源

使用Appan/Cordova/PhoneGap等框架通过WebView加载本地资源进行页面渲染

优点：

跨平台，开发高效以及快速发布上，

将资源打包到本地也可以在一定程度上缓解从远端加载静态资源导致UI展示延迟的问题，并且还可以通过桥接Native和Web来调用一些Device的API

缺点：

WebView执行代码效率较低，很难实现一些炫酷的效果，

存在不同设备的兼容性问题；

应用中用到了大量的Device API时，开发的效率将大大降低；

很难应用到平台相关的新特性，比较难做出有特色的产品

使用H5页面来实现纯展示页面是非常推荐的一种方案，而AppCan/Cordova/PhoneGap则更适用于对预算有限的公司和开发团队

4. React Native

React Native是Facebook开源的技术。

优点：

React Native的理念在于“Learn Once, Write Anywhere”。

React Native整套的逻辑代码都通过JavaScript实现，这样就让跨平台应用能够方便的复用逻辑代码。

View层的部分通过原生组件实现，性能比其他WebView的方案好很多

缺点：

虽然大部分代码是平台无关的，但是平台相关的代码都需要单独实现，对跨平台带来了不便

React推出时间不长，还不够成熟，尤其对于Android平台。

React Native对复杂动画效果有欠缺，很难达到Native的程度。

特不正经的小结： 以上应该够清楚了，不用小结了。:-)

V、大数据架构 vs 传统架构

传统应用数据的典型架构是关系型数据库如Oracle或MySQL，或者微服务+RDB的架构

大数据应用架构的典型架构：

什么时候用大数据，什么时候用传统架构？

1. 数据量

对于数据量来说，一般来讲50TB是一个分水岭，超过50TB数据的应用优先大数据架构。

对于数据量较大，但对性能很敏感的应用，大数据的Spark和Stream是非常好的架构方案选择。

2. 分析方法

传统的数据分析通常都有成熟的模型，强调因果关系的分析，通常是多维OLAP建模，已知数学模型。

而大数据分析强调的是关联关系，通常用机器学习算法，对数据进行深入挖掘，发现未知的关系。

如何选择SQL vs NoSQL vs NewSQL vs Hadoop？

本篇推文太长了，下次再说吧.....

最后，特不正经做个总结：

不能为了微服务而微服务，单体应用有时也挺好

不能为了REST而REST，RPC长得丑但很壮

不能为了API网关而API网关，不要嫌弃ESB太老，也不要光看网格漂亮

不能为了Native而Native，H5虽然慢也有用处，React使用要研究透

不能为了大数据而大数据，你要啥才需要啥！

尼玛，简直了，说了等于没说啊！没看懂？再仔细看一遍，哈哈哈哈哈.....

************************************

“特不正经”是我个人的公众号，欢迎关注！

本公众号主要内容为IT发展趋势研究和IT人的生活，包括数字化转型，信息安全，大数据，应用整合，DevOps和云，IT程序猿，销售狼，咨询狮, 老板狗的生活，天文，地理，哲学，人文等无所不包的不正经内容。

特不正经是一个酱油马拉松跑者，非著名诗人，主修哲学，从事修路，挖湖，抓鬼打怪的软件狗（派拉软件专属）...