我理解中的应用架构
这些年互联网的快速发展，分布式，微服务的概念风靡整个行业。在企业中IT的架构，从过去的单体应用架构发展到现在广为人知的微服务架构。不说别的，现在出去面试都不好意思说自己不知道微服务。微服务是一种架构风格，将我们的业务拆分若干个服务，为我们的开发带来了极大的便利。过去，架构是从单体应用架构-->分布式架构-->微服务发展。
单体应用架构
这种架构在老的Java web项目中还存在，就是一套代码撸到底。就是项目中从controller到service再到dao层，不进行任何的拆分，所有的代码都堆积在一个项目中。这样打出来的war巨大无比，启动都要费好多时间。比如下面的例子：
这样就把供应链所有的的功能业务代码放在项目中，可想而知，代码量有多大。不过这种架构方式既有缺点又有优点优点：
- 简单方便，易于开发。所有人员都在一个项目上做开发，没有接口的远程调用，很方便。
- 相对容易测试以及部署运维。打包成测试包之后，部署到测试环境即可从头到尾进行测试。而且不受网络影响
- 缺点：
- 代码不易管理。没有进行拆分，也就是所有的开发人员都在一个项目上提交代码，就会出现我们非常恶心的代码冲突~
- 代码耦合度高。可能仅仅修改一小个代码，就会导致整个系统出现问题，不敢下手随意修改代码啊，泪奔~
- 系统扩展性差。要增加或者上线某个小功能的时候，整个应用都得停下来部署，用户体验太差了~
- 系统启动慢。毫无疑问，模块太多了也是一种累赘。
- 因此这种架构慢慢被淘汰，衍生出分布式架构
分布式应用架构
分布式架构从业务的不同进行拆分，将我们的单体应用拆分多个业务服务系统，每个服务系统就是一个单体应用，他们之间通过商定好的api进行调用。例如将上面的例子拆分，将庞大的供应链系统拆分成采供管理系统，资产管理系统，仓储管理系统：
这种拆分，大大降低了代码的耦合度，提高了服务的可用性。从原来一个大项目重新分配任务小组，每个小组负责自己的业务项目，业务服务之间通过api调用，每个服务模块运行在不同的主机上。当然这种分布式架构一下子表现出的优点也表现出缺点。优点：
- 降低了业务模块之间耦合度。将模块拆分之后，通过接口进行调用，其他业务代码不受影响。
- 项目细分化，不同的项目组负责不同的任务。
- 系统扩展性高，灵活。增加或者改造某个功能时，不需要牵一发而动全身影响到别的模块。不会存在因为其他服务不存在而造成我自己的服务不能启动或者不可用的问题。
- 缺点：
- 受网络影响。系统之间经过api远程调用，不仅增加了接口开发工作量，而且受网络限制。
- 数据的一致性问题。
- 增加了运维工作量。
- 这种分布式架构按照角色来划分，分为：生产者（服务提供方），消费者（服务调用方）。
- 应用场景：项目中使用kafka就是一个分布式系统。
微服务应用架构
其实90%的微服务架构就是分布式架构一种延申。微服务的概念最早源于Martin Fowler发表的一篇《Microsevices》。这种微服务按照业务的功能继续拆分成相互独立的微服务，各个微服务之间是松耦合的，也是通过远程协议进行调用。例如我们将采供管理再一次拆分，将采供管理系统拆分成需求管理，采购管理，入库管理：
这种拆分方式将分布式应用架构更加细分化。各个微服务之间通过各种远程协议进行同步/异步调用，各个微服务之间也是独立部署。当然这种服务架构也同样。除了具备分布式架构的缺点外，还有：
- 通信，http请求速度慢，通常一个操作可能会涉及到多个微服务的相互调用，如果为了完成一个操作而多次从服务端调用不同的微服务，http请求的耗时可能会成为瓶颈。
- 增加复杂性以及加大 了技术支持。在微服务中不仅仅服务之间的调用这么简单，还需要许多技术支撑，比如服务注册中心，熔断器，链路跟中，分布式配置中心，分布式事务等等技术上的支持，加大了开发人员的额外任务量。
- 服务众多，其测试，部署，监控变得更加复杂。
- 下面这张是从网上拷贝下来的微服务架构图，可以看出来需要好多技术来支持构成完整的微服务架构：
- 当然这种带来的弊端远远小于带来的好处。
微服务技术方案的选型
市面上支持微服务的技术栈是多种多样的，但是按照现在比较流行的，无非就是springcloud以及dubbo方案。springcloud是spring社区下的项目，提供了完整的落地方案，包括服务发现，网关，配置中心，链路跟踪等。而dubbo是阿里巴巴基于java分布式服务治理框架，但是它没有提供完整的解决方案，而是专注于RPC领域。两者技术选型对比：
当然了，我们在实际中不能光是微服务而微服务，要根据具体场景来选型。选择适合自己业务的架构，才是最好的架构。
以上是我本人对应用架构的理解，如果有不对之处，证明本人学业不精，还望各位理解谅解。
本人水平有限，难免有错误或遗漏之处，望大家指正和谅解，提出宝贵意见，愿与之交流。
