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读写速度。数据库
-
优势：简单有效，减小对 DB 的查询缓存
-
缺点：增长逻辑判断，不适合存储大对象。
二，消息队列在对一个同步的机制化解成异步处理，主要目的是减小请求响应时间和解耦，以便提升吞吐量。
服务器
-
优势：异步、解耦，提升吞吐量微信
-
缺点：消息消费延迟等问题架构
三，任务调度以任务方式，实现任务的调度，这个有利于资源的分配，例如：闲时作数据清洗（ELT），数据库备份，消息推送等。
并发
-
优势：利用闲时提升资源的使用量，负载均衡
-
缺点：带来开发成本以及维护成本框架
四，搜索引擎中间件替换数据库的实时查询，例如：多表关联查询，视图查询，通常能够采用搜索引擎机制进行查询。dom
-
优势：利用索引能够替换多表联合查询，视图查询，减小数据库查询带来的不便性
-
缺点：要作到实时数据有点困难
五，数据挖掘引擎能够搭配HADOOP，SPARK进行实时运算，并把实时结果返回。
6、数据分库
先垂直后水平的原则，根据业务的进行解藕，通常按业务的来划分，由于前面搭配了搜索引擎，以及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