架构是什么？

    IT生涯将近10年，一直对于软件架构还是将懂非懂，因为每一个团队的经历不一样，所以达到的高度也不一样，所以经历决定一个架构师的水平能力（腾讯的架构也不一定适用中小型，做ERP的不一定适合互联网），也由于行业的特性，所以架构也随环境，行业特性，团队水平性而产生裂变，所以说团队的技术水平决定架构的层次，再加上架构也是具有一定的发展性（从最初的三层架构，MVC，SAAS，DDD，微服务），所以一直以来，架构在每一个团队，或者整个软件行业一直都是雾里看花，也就造成每一个团队都有自己的一套架构标准。

 

 

一,好架构的标准

    一个好的架构，必然跟目前的技术推进相关，好的架构必须具备以下的规则：

1，适应于多人开发，保证开发质量的前提下，尽量以效率为主，所以为什么要用ORM，接口规范，公共层，代理层，数据库设计规范，这些都是为了效率，减少重复代码工作量，以节省开发时间。

 

2，良好的可伸缩性，扩展性，所以才有了架构的行业规范。从架构的迭代，大多数人都经历三层架构，MVC，MVP（WEB FROM ），SAAS，DDD，微服务，组件，插件化，架构，这些的技术单一或者混合在使用，这些都是为了伸缩以及可扩展性，并且由于一般大型的开发，人员很多，所以把每一个大型的系统拆分成子系统，有利于松藕及管理，所以一个大型的系统拆分子系统又有很有必要，像淘宝，分支付系统，商品系统，搜索系统，存储系统等。

 

 

3，为了应付大并发，海量数据，不同的小组工作成员分工，那么就大量的中间件运用而生,而分布式的中间件大量产生，缓存（Cache），消息队列（MQ），任务调度（JOB），搜索引擎，存储引擎，数据库读写分离，数据挖掘引擎，大量应用而生，所以导致很多人认为架构不与这些沾上边，就是以为那就不是好的架构，因为这些的应用场景比较缺，所以也是考验一个开发的技术水平，没有平台给你做实践，天天谈技术纯粹扯蛋，只要真的踩坑，才是出真理。

 

4，不同的行业背景，架构也不一样，举个例子：

 

ERP类行业标准：金碟的K/3系统，之前每一个库留几十个字段，那是因为客户端以及服务端到实施他没有云化，所以预留字段很有必要，所以大型应用组件及插件，客户在实施的时候，需要什么，按需调用，为了灵活性及通用性。

 

互联网类的标准：从最初的三层架构，到SAAS（SOA，软件即服务），DDD（领域驱动），微服务，每一个技术的发展，其实是跟整个互联网的背景有关，为什么会有微服务，其实是跟技术环境有关系，由于互联网代表新兴的技术推进，面临各种技术的混合使用，云平台的诞生，所以才会有微服务的存在，微服务最大的优点就是为了跨平台以及跨语言，其缺点也很明显，可能导致重复的工作。

 

那么，归纳起来，衡量一个架构的好坏，可以从以下5个方面 去考虑大并发，海量数据，扩展性，独立性，业务延伸五个方面去达到考虑一个架构的规范及严谨性。

 

 

 

按照以上的五个标准，那么我根据自己的水平以及层次，建立一套好的框架标准，肯定是要考虑结合实践场景，那么客户必须满足三个端，网站（PC与移动），APP，物联网硬件，而服务端必须满足独立性，扩展性，大并发及海量数据，如电商为例：

 

 

1,服务端，可划分为载体，构件层，组件层，（载体是指，WEB项目，WEBAPI，SOCKET服务中心管理，任务调度管理中心，构件层很重要的一个功能就是将系统资源与应用构件隔离，这是保证构件可重用甚至"即插即用"的基础，与中间件的意图同样是一致的，简洁理解为，构件可以加载到任务载体，载体可以随便选择构件，通过IOC就可以实现他的功能引用，组件就是元件）即插即用，用到这载体，构件化，组件化，实现扩展性，独立性，业务延伸的一个标准。

 

而把运营支持组件，嵌入到组件里面去，可以实现支撑大并发，海量数据，有利于系统的统一性，而运营组件最大目的就是支撑大并发以及海量数据，例如：缓存减少IO读写，消息队列把同步变成异步，多表联合查询用搜索引擎替换，NOSQL，HADOOP替换了数据库运算……

而这样就有了一个好的架构，那么说一说规范以及技术在架构的应用以及规范，架构的目的是在于规范，而规范遵守三个标准：约定、规则、共识。

 

 

一，组件的标准定义，拥有数据实体层Model，服务层Services，数据层DAL.

约定标准以下：

1.1，MODEL层的规则就是可以建立数据表之间的一对多，或者一对一，超过之外的视图模型统一放到构件层的DTO（WEB API），或者载体（WEB项目）的MODEL管理，以便减少维护成本。

1.2，Services尽量以接口暴露出来，加上IOC可以注入到任何的载体容器里面去。如JAVA的SPRING框架，NET的WEBAPI，MVC框架。

 

1.3,services层调用DAL尽量引用单例模式，这样在读写分离起到作用。

 

1.4，ORM的标准，支持不同的数据库类型，例如：MYSQL，NOSQL，MSSQL，ORACLE，框架选型，根椐不同的开发语言，做不同的选型，最重要的一点，支持读写分离。

 

1.5在services层添加一个IOC的接口配置文件，这样把IOC配置在WEB项目，或者WEBAPI这样的载体上面上。

 

二构件的标准定义：

2.1 独立的路由URL，Controller，DTO，所有的数据来源都是组件。为什么会需要构件？在软件交互的时候，很多时间我们面临三个问题：

1：由UI，客户端，第三方接口与目前的系统模型没法对应，需要过滤及组装。

2：需要对内外统一通过URL路径及通讯协议。

3：跨平台，降低程序的复用性，一个暴露的接口，每个子系统都可以引用。

 

 

运营组件的标准：

1，分布式CACHE，作二级缓存使用，减少IO读写，以应用大并发，以内存读写速度换IO读写速度。

2，消息队列，在对一个同步的机制化解成异步处理，主要目的是减少请求响应时间和解耦。

3，任务调度，以任务方式，实现任务的调度，这个有利于资源的分配，例如：闲时做数据清洗（ELT），数据库备份，消息推送等。

 

4，搜索引擎中间件，替换数据库的实时查询，例如：多表关联查询，视图查询，一般可以采用搜索引擎机制进行查询。

 

5，数据挖掘引擎，可以搭配HADOOP，SPARK进行实时运算，并把实时结果返回。

 

运营组件的标准：

一，分布式CACHE作二级缓存使用，减少IO读写，以应用大并发，以内存读写速度换IO读写速度。

1. 优点：简单有效，减少对 DB 的查询

2. 缺点：增加逻辑判断，不适合存储大对象。

二，消息队列在对一个同步的机制化解成异步处理，主要目的是减少请求响应时间和解耦，以便提高吞吐量。

1. 优点：异步、解耦，提高吞吐量

2. 缺点：消息消费延迟等问题

三，任务调度以任务方式，实现任务的调度，这个有利于资源的分配，例如：闲时做数据清洗（ELT），数据库备份，消息推送等。

1. 优点：利用闲时提高资源的使用量，

2. 缺点：带来开发成本以及维护成本

四，搜索引擎中间件替换数据库的实时查询，例如：多表关联查询，视图查询，一般可以采用搜索引擎机制进行查询。

1. 优点：利用索引可以替换多表联合查询，视图查询，减少数据库查询带来的不便性

2. 缺点：要做到实时数据有点困难

五，数据挖掘引擎可以搭配HADOOP，SPARK进行实时运算，并把实时结果返回。

• 优点：可以代换传统数据库的实时运算，并根据算法达到最优

• 缺点：需要数据清洗，不同的算法来做不同维度的模型，技术含量高。

六、数据分库

先垂直后水平的原则，根据业务的进行解藕，一般按业务的来划分，因为前面搭配了搜索引擎，以及HADOOP来替换数据库的实时运算，一般没大问题，所以前提尽量先拆库，再拆表。

数据库标准：

前期尽量按业务或者子系统分库，另外数据库的设计标准，尽量减少字段以及字段存储，达到以空间换时间的效果，即存储量越小，查询越快。

谈完以上，就可以开始着手搭一个架构出来，再根据业务场景去进行编码去，规范再定义好数据库规范，代码审核规范，即可以完成一个软件架构了。

当然，实时这些，只能是从软件架构的实现，现实还要进行

1.    数据库服务集群（一写多台读）

2.    文件服务集群。

3.    缓存服务集群

4.    应用服务集群

5.    负载均衡调度器集群

6.    静态内容服务集群

7.    CDN服务器集群

优点：去单点，高可用

缺点：数据有状态问题、数据一致性问题，资源成本、人力维护成本都上去了。

这样一个大型的网站架构就完成了但这也面临一个很现实的问题，一个网站的流量并发有高有低，包括发布，在一百台机器发布程序以10台发布完成不一样，还有多个子系统，发布简直就是浪费人力成本，而 DT/分布式 时代的到来，大流量和大数据的场景的出现，包括Docker ，Kubernetes技术的产生，一度催生了微服务架构。

微服务架构

微服务架构（microservices architecture）一度成为热点，微服务并不是凭空出现，有人说，它是面向服务架构（SOA）的升级，在此之前，还有诸如集中式架构、分布式的架构等。这里借用一副抽象的图来描述下常见的几种架构：

微服务架构由多个微小服务构成，每个服务就是一个独立的可部署单元或组件，它们是分布式的，相互解耦的，通过轻量级远程通信协议（比如REST）来交互。每个服务可以使用不同的数据库，而且是语言无关性的。它的特征是彼此独立、微小、轻量、松耦合，又能方便地组合和重构，个体简单，但组合起来威力强大。

优点：扩展性好，服务之间耦合性低，服务间相互独立，容易部署，易于开发，方便测试每一个服务

缺点：容易过度关注服务的大小，可能拆分地很细，导致系统依赖于大量的微服务，而服务之间的相互通信也会变得复杂，系统集成复杂度增加，很难实现原子性操作。

微服务之所以这么火，另一个原因是因为 Docker与Kubernetes(k8s) 的出现，它让微服务有一个非常完美的运行环境。Docker 的独立性和细粒度非常匹配微服务的理念，Docker的优秀性能和丰富的管理工具，让大家对微服务有了一定的信心，概括来说 Docker 有如下四点适合微服务：

独立性：一个容器就是一个完整的执行环境，不依赖外部的任何东西。

细粒度：一台物理机器可以同时运行成百上千个容器，其计算粒度足够小。

快速创建和销毁：容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。

搭配Kubernetes(k8s)开源的容器集群管理系统，能够快速地实现服务的组合和调度，例如云计算机租用，闲时，就销毁计算机资源，忙时增加ESC，就是几分钟的事情，还可以实现多租户的使用。

Kubernetes  +DOCKER

当然搭配Kubernetes+jenkines持续集成，可以发布到开发环境，测试环境，生产环境，更是自动化的事情，架构在迭代，做架构其实一直在学习中前进，好的架构和技术要应用于实践，保持一颗学习的心，才是立根之本。

作者：BON,微信公众号：ithaidao