一、架构的目的
降低成本、提高效率
二、架构的定义
什么叫架构？
1、架构是场景抽象化得出的骨架。
举例，电商系统，一般的电商的业务模型可能就包含如下几部份：商户（卖家）、商品、销售记录、买家、订单、评价、付款、个人帐单。
例如，买家通过卖家发布的商品，然后产生订单、付款、对买家自动产生个人帐单、对卖家产生销售记，收到该商品后，对商品下的订单给评价。
举例，工作流包含的技术骨架包含：流程的定义、流程引擎、流程的实例、每个实例又包含开始节点、任务节点（处理人、处理事情、状态）、节点关系（并行、串行、分支）、结束节点。
业务特征：1、序列关系（先做什么后做什么）
2、状态机（数据驱动流转状态，走到哪个阶段，哪个审批人、哪个阶段什么成功、失败、驳回、通过、等待）、3、可预测性。例如，一个请假流程，有先做什么、再做什么，有顺序关系的（序列），这个请假流程走到经理审批（状态），下一步该怎么做，是可以预测的。
举例，权限的骨架（操作主体、操作的对象、操作动作（增、删、改、查），如xx操作主体，对xx对象，执行了xx操作，我把门打开了，我是操作主体，门是操作对象，动作就是打开。
2、架构为场景而生，被场景所抛弃，受制于人员的研发能力、业务复杂度、数据规模、时间成本、运维能力，最适合的架构是各中折中平衡的体现。
举例，假设现段微服务是最好的。确实微服务能让你的业务迭代更快。但是实现微服务之后带来系列问题，比如说你的服务数量会增多。网络之间服务之间会增加通讯、还要有些服务治理（注册中心、配置中心、监控、熔断、降级），这些都需要配套的，但是老板说了只给你两个人来做，在一个月时间必须完成上线，如果用微服务架构你把我杀了，也做不完哈。所以基于现在的业务场景、人力成本、时间成本，微服务并不合适，单体架构可能是最合适的。没有最好，只有最适合的哈
一切脱离场景的架构，都是耍流氓。
三、架构的演变
整体演变过程顺序：单体架构、SOA面向服务架构或分层架构、再到微服务架构、再到网格架构。
其本质可能就是怎么“拆”的过程，基本上是水平拆分和垂直拆分。
3.1 单体架构的问题
首先单体架构，把A业务、B业务、C业务的处理请求、访问数据库、业务逻辑处理、封装结果返回，都丢在一个web容器里处理，带来的最大的问题是耦合性太高，给开发、布署带来一系列的问题。
所有的代码都整一起，如开发A改了一点代码，影响其B功能不能用了，例如，布署时，改点需求，整个系统都要停机。例如，我曾经见过系统一百多个模块，几百个开发人员，代码都整在一起，就光在开发环境运行来，都要等一二十分钟，几百个人都要启动开发环境，算算这个效率和时间要多少呢？
3.2 单体架构问题怎么解决，用分层和soa服务，会出现什么问题
怎么破耦合性太高的问题？就是拆，
水平拆，按请求过程功能维度，拆层分层的，每层独立开发、布署、独立进程
大致如下几层：处理请求成网关层、数据访问层（这层技术相对比较难）、业务逻辑层（处理业务逻辑较容易）、结果返回层。例如 以前比较流行时mvc模型，也这种拆分的思路。
垂直拆，按业务维度，拆分基于SOA的服务，服务下面再n个接口，每个服务独立布署、独立进程，再加个总线代理层进行服务间的相互通讯，就成了完整的服务总线。
例如，假设电商里有用户、商品、交易，原来整一起，现在用户一个单独服务、商品单独的服务、交易是单独的服务。
大家想一想基于这种水平和垂直拆会有什么问题呢？
垂直拆分，其本质还是单体应用，所以的业务还是在一起，耦合性还是有点高。
水平拆分，整成soa服务，业务是分开了，但是从技术角度看，还是比较复杂。
例如数据服务层是最难的，假设数据量到一定级别后要sharding，对象ORM等，要屏蔽不同数据库差异性，需要一定的技术含量，写好了，轻易不要改。而业务逻辑层最不稳定，技术含量不高的。对人的要求也不一样，这两者耦合在一起，又会带来问题，业务迭代会变慢阿。
3.2 解决服务化或分层的问题，用微服务方式，微服务会出现什么问题？
所以，微服务架构出世了，
微服架构思路就是业务的垂直拆分+功能水平拆分。
例如电商，先是统一网关层，用户逻辑层、用户数据访问层、用户db层，商品逻辑层、商品数据访问层、商品db层。
甚至有垂直拆分再细分、按api接口，例如用户服务下面又分、用户注册服务（逻辑层、数据访问层、DB层）、用户登录服务（逻辑层、数据访问层、DB层）等。
这样解决了上面提到业务迭代慢的问题，以微小增量的模式进行开发。
大家再想一想微服会有什么问题呢？
服务切分粒度更细，为了保障大量不同服务之间的通讯正常，不同协议服务要通讯，就需要很多通讯组件，如服务的注册与发现、服务路由、服务的熔断与重试、服务的配置中心等等，而这些通讯组件是和业务服务绑定在一起，这些是架构部在维护，不同服务可能不在一个体制下，造成基础设施不一样。 例如，我曾经碰到，我们公司的微服务版本相对超前，而对方公司的微服务还是以前老思路，要把对方的微服务注册到我方服务注册上，发现匹配不上，后来要求对方升级，对方公司完全业务驱动型的，对我们讲，他们业务因为很久没改动，把基础设施那团队都砍掉了，只剩下写业务代码团队，根本就没这个能力，而且业务又没改动凭什么要升级，心塞阿。所以你看，这些基础设施升级是超极困难的，影响基础设施团队的交付能力和交付速度的。
3.4 解决微服务出现的问题，用服务网格思路。
所以，服务网格service mesh的思路出现了。
主要思路，原来服务和服务之间通讯，现每台机器，搭建个轻量的代理sidecar,不同机器的服务之间不直接通讯了，而是由sidecar负责，把原来那些服务通讯组件都移到这个代理里面。
四、架构演化
所以，你看，单体架构，所有的都耦合在一起的问题，转到分层或基soa服务，不适合复杂业务迭代微小增量变快的问题，到微服务，复杂的服务通讯组件和业务耦合太深不利于架构升级，再到服务网格轻代理架构，就是架构的演变过程，所以好的架构不是设计出来，而是不断解决出现的问题，演化而来的。
下面的章节，会写每个架构的详细功能、技术特征、使用场景等，拭目以待吧！