《微服务架构与实践》学习笔记一：微服务架构理论

一：单块架构应用面临挑战

单块架构应用：功能集中（围绕一个主题而实现）、代码和数据中心化管理与存储、一个发布包（各层整合到一起进行发布）、运行在同一电脑同一个进程中的应用，称为单块架构应用。

举例：传统J2EE项目，整合成一个war包，部署到一台服务器中运行。

面临挑战：

业务扩大、需求增加，使得系统规模变大，难以维护与更新，牵一发而动全身。

同时，项目大了，开发周期变长（因为要整合到一起发布）。

技术转型成本高：单块架构应用使用统一的技术平台，团队人员掌握的都是相同的语言和技术。当新技术出现时，项目转型成本高。因此，单块架构项目一开始的技术选型将严重限制日后的技术过度与新技术新框架的引入。

MVC架构带来项目分层开发的同时，也带来了开发团队之间的沟通成本问题（比如前端工程师与后端工程师之间的沟通），而且项目规模越大，跨团队沟通成本越大，需要培养全能型人才。

二：微服务架构综述

微服务架构的定义：

微服务架构是一种新型架构模式。

它将单一的、集中的应用划分为一组小服务，服务之间互相协调互相配合，共同为用户服务。

与单块架构应用不同的地方在于，微服务架构的每个服务运行在独立的进程中，服务之间的协调合作通过轻量级的通信机制（基于http的RESTful API）来完成，而单块架构应用则是通过同一进程内的线程通信来协作。

每个服务作为单元，围绕一个具体的业务进行构建，并且能快速地部署到生产环境中。

最重要的是，为了避免统一的、集中的技术，对于每一个服务，应根据具体业务来选择合适的语言、工具、技术、框架来进行构建，以加快开发并适应技术潮流。

三：微 的划分

业务微：根据业务的独立性来划分服务。

团队微：团队规模不超过十人，并且由不同技能、不同角色的成员组成，是一支全功能的团队。

四：特性

1:单一职责：一个服务其业务职责单一。

2:轻量级通信：轻量级通信的含义是，通信机制与平台／语言等耦合低。我们熟知的xml/json就是无关平台等通信格式，而当下，基于http的rest能使服务之间的通信更加标准化。

3:独立性：开发／测试／部署独立。

4:进程隔离：不同服务运行在不同机器的不同进程中。

【实质：以服务作为组件，围绕业务组织团队，技术多样，以通信来协作】