微服务--概念

传统单体架构

---

经典3层模型

• 表现层：交互层，用于直接与用户交互。通常指网页，UI
• 业务逻辑层：业务逻辑处理层
• 数据访问层：用于操作数据库

经典的单体架构

• 表现层、逻辑层、数据访问层在一个工程，编译打包，部署在一台服务上。
• 经典的J2EE工程：表现层JSP、业务逻辑层Service Controller和数据访问层Dao ，打成war包，部署在tomcat等其他的servlet容器中运行。
• 经典的部署方式LMAP
  

单体架构优势

• 开发快速
• 运维难度低、系统管理方便
• 服务器成本低

单体架构不足

• 不停迭代，代码量冗余，可读性、可维护性和可扩展性下降。
• 单体应用并发能力有限
• 单一系统，并行困难，不利于告诉迭代

单体架构服务器集群

• 负载均衡：处理高并发网络请求，将访问分派到不同的应用服务器。软负载：nginx等，硬负载：F5等
• 应用部署集群：横向扩展，高可用。用户量增加，扩展服务器即可。
• 缓存服务器：提高响应速度，缓解数据库压力。
• 数据库：主从备，读写分离 ； 分库分表

单体架构服务器集群的不足

• 单体应用，代码量依旧冗余，可读性、可维护性、可扩展性还是欠缺。
• 海量访问，数据库依旧是瓶颈。
• 单应用依旧迭代缓慢，持续交付能力差

由此可见，在应用初期，单体应用从成本、开发时间和运维方面有优势。但随着业务量和用户量增加，缺点也显而易见

微服务

---

什么是微服务

• MicroServices
• 微服务最初是由Martin Fowler提出来的他的理解如下：
  微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。
• 特点：
  • 服务单元：按业务划分独立的运行程序
  • HTTP协议互相通信
  • 自动化部署
  • 支持不同语言，不同存储技术
  • 服务集中化管理
  • 分布式系统
  • 熔断机制

微服务的优势

• 复杂业务拆分小业务，每个业务拆分一个服务，服务边界明确；简单化，代码可读性和可扩展性好
• 服务与服务之间耦合度低，随着业务的增加，可以再拆分服务，具有极强的横向扩展能力。
• 服务间通过HTTP协议通信，支持新老系统的交互，支持异语言，异架构的系统交互
• 服务切分后各自直接高度解耦合，单服务重构简单，新人学习成本降低，上手简单
• 微服务独立部署，对并行修改、迭代，方便快速持续交付
• 微服务在CAP理论中采用AP架构，具有高可用和分区容错的特定。

微服务的不足

• 微服务的技术复杂度：涉及较多的微服务技术，构建一个微服务系统远比单提系统复杂，有一定的学习成本
• 分布式事务：每个服务都是独立的单元，CAP理论中，分布式是AP架构，所以数据强一致性需要做额外的处理
  • 两阶段提交，事务协调器
  • 业务逻辑补偿
• 服务的划分
• 服务的部署和管理
  • 服务的治理，监控和管理；大量的配置。服务的启停顺序
  • 基于云服务器，Docker编排（微服务最佳部署容器），DevOps（部署手段或理念）；

微服务应具备的功能

• 服务的注册和发现
• 服务的负载均衡
• 服务的容错
• 服务网关
• 服务的统一配置管理
• 链路追踪
• 实时日志

微服务和SOA的关系

• SOA：中心化
  • 面向服务的架构，往往与企业服务总线（ESB）联系在一起。
  • 实施思路是根据ESB模式集成大量单一庞大系统的落地方式。
• 微服务：去中心化
  • 组件化，敏捷化
  • 点对点