【Microservice】Microservice Common Sense

 微服务是一种应用程序架构风格，它将应用程序划分为组件，其中每个组件都是一个完整但微型的应用程序，专注于根据单一责任原则生成单个业务任务。从GUI到数据库或从服务API到数据库，以便不同的GUI和客户端应用程序可以重用相同的业务任务功能。每个微服务都有明确定义的接口和依赖关系（例如，对于其他微服务和外部资源），以便微服务可以相当独立地运行。

        微服务的宗旨：使得开发更高效。通过最大限度地减少人与人之间的沟通和协调它（少一些会议多一些开发等），以及减少变更范围和风险来加速交付。

       微服务架构的目标是将app组件彼此完全decouple/分离，以便可以维护、扩展等。微服务架构如下：

===========【SOA VS Microservices】================

·     SOA/service-oriented architecture : Focus on reuse, technical integration issues, technical APIs

·     Microservices: Focus on functionaldecomposition, business capabilities, business APIs

翻译为：

·     SOA：专注于重用，技术集成问题，技术API

·     微服务：专注于功能分解，业务功能，业务API

 

=====【Key tenets of a microservices architecture】====

1)   大型整体结构分为许多小型服务

·      每个服务都在自己的进程中运行

·      适用的云规则是每个容器一服务

2）服务针对单个功能进行了优化

·      每项服务只有一个业务功能

·      单一责任原则：微服务应该只有一个改变的理由

3） 通过RESTAPI和消息代理进行通信

·      避免通过DB通信引入紧密耦合

4） 每个服务定义CI/CD（持续集成和持续部署）

·      服务以不同的速度发展

·      设置架构原则以指导系统进化发展

5） 每个服务定义HA（高可用性）和群集决策

·      一种规模或扩展策略并不适合所有微服务

·      并非所有服务都需要扩展，其他微服务需要自动扩展到大数

===========【Monolithic VS Microservices】===========

/	Monolithic	Microservice
架构	以单个逻辑可执行文件构建	以一套小型服务构建
模块化	基于语言功能	基于业务能力
敏捷度	更改涉及构建和部署整个应用程序的新版本	更改可以独立应用于每个服务
扩展	当有一部分是瓶颈时，需要整个应用程序进行扩展。	每个服务在需要时独立扩展
实现	通常全部由一种编程语言开发实现	每种服务都可以用不同的编程语言开发实现
可维护性	大型代码库对新开发人员是一种intimidating/威胁	较小的代码库更易于管理
部署	复杂部署，需要维护窗口和计划停机时间。	简单部署，因为每个服务都可以单独部署，停机时间最短。

       微服务最大的要求是操作复杂性，因为有更多的移动部件需要监控和管理，一个大型的业务需求有可能需要上千个应用程序，这就需要管理和监控上千个应用程序运行情况，这对企业来说是个巨大的挑战。微服务存在的隐患：

·     微服务重视服务之间的重用独立性，重用会产生依赖关系就会存在团队之间的交互因此无法独立工作。

·     独立运行的部分越多，分布式系统就会越成为问题（网络延迟、断开连接、容错、序列化）；那么找到bugEnd2End测试难度就会增加。

============= Microservice Advantages ==============

·     独立开发，并对其他服务存在有限的、显式的依赖

·     可以由一个所有团队成员都理解整个代码库的小团队开发

·     根据本团队时间表开发，以便独立于其他服务提供新版本

·     独立扩展和失败，可以隔离任何问题，不影响整个app

·     每种服务都可以用不同的语言开发实现

·     管理自己的数据以选择最佳技术和架构