相逢意气为君饮，系马高楼垂柳边。这篇文章主要讲述后台应用架构（单体SOA微服务）理解相关的知识，希望能为你提供帮助。
后台应用架构
单体架构
- 传统架构（单机系统），一个项目一个工程：比如商品、订单、支付、库存、登录、注册等等，统一部署，一个进程
- all in one的架构方式，把所有的功能单元放在一个应用里。然后把整个应用部署到一台服务器上。
- 如果负载能力不行，将整个应用进行水平复制，进行扩展，然后通过负载均衡实现访问。
- java实现：JSP、Servlet，打包成一个jar、war部署
- 易于开发和测试:也十分方便部署;
当需要扩展时，只需要将war复制多份，然后放到多个服务器上，再做个负载均衡就可以了。
- 如果某个功能模块出问题，有可能全站不可访问，修改Bug后、某模块功能修改或升级后，需要停
- 掉整个服务，重新整体重新打包、部署这个应用war包，功能模块相互之间耦合度高,相互影响,不适合当今互联网业务功能的快速迭代。
- 特别是对于一个大型应用，我们不可能吧所有内容都放在一个应用里面，我们如何维护、如何分工合作都是问题。如果项目庞大，管理难度大
- web应用服务器：开源的tomcat、jetty、glassfish。商用的有weblogic、websphere、Jboss
微服务
- 属于SOA（Service Oriented Architecture）的子集。微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底去掉耦合，每一
- 个微服务提供单个业务功能，一个服务只做一件事。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等
- 从技术角度讲就是一种小而独立的处理过程，类似与进程的概念，能够自行单独启动或销毁
- 微服务架构（分布式系统），各个模块/服务，各自独立出来，"让专业的人干专业的事"，独立部署。分布式系统中，不同的服务可以使用各自独立的数据库。服务之间采用轻量级的通信机制（通常是基于HTTP的RESTful API）。
- 微服务设计的思想改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端、后端、DBA、测试分别有自己对应的团队，属于水平团队组织架构。而微服务的设计思想对团队的
- 划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。但实际上在企业中并不会把团队组织架构拆分得这么绝对，垂直架构只是一种理想的架构
- 微服务的实现框架有多种，不同的应用架构，部署方式也有不同
单体架构和微服务的区别
微服务的优缺点
微服务优点 - 每个服务足够内聚，足够小，代码容易理解。这样能聚焦一个只当的业务功能或业务需求。
- 开发简单、开发效率提高，一个服务可能就是专业的只干一件事，微服务能够被小团队单独开发，这个小团队可以是2到5人的开发人员组成
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。微服务能使用不同的语言开发
- 易于和第三方集成，微服务运行容易且灵活的方式集成自动部署，通过持续集成工具，如:Jenkins、Hudson、Bamboo
- 微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值
- 微服务允许你利用融合最新技术。微服务只是业务逻辑的代码，不会和html/CSS或其他界面组件混合，即前后端分离每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库
微服务缺点 - 微服务把原有的一个项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂度
- 微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战
- 开发人员和运维需要处理分布式系统的复杂性，需要更强的技术能力
- 微服务适用于复杂的大系统，对于小型应用使用微服务，进行盲目的拆分只会增加其维护和开发成本
常见的微服务框架
Dubbo - 阿里开源贡献给了ASF，目前已经是Apache的顶级项目
- 一款高性能的Java RPC服务框架，微服务生态体系中的一个重要组件
- 将单体程序分解成多个功能服务模块，模块间使用Dubbo框架提供的高性能RPC通信
- 内部协调使用Zookeeper，实现服务注册、服务发现和服务治理
Spring cloud - 一个完整的微服务解决方案，相当于Dubbo的超集
- 微服务框架，将单体应用拆分为粒度更小的单一功能服务
- 基于HTTP协议的REST(Representational State Transfer 表述性状态转移）风格实现模块间通信
【后台应用架构（单体SOA微服务）理解】
推荐阅读
