这是我参与「第三届青训营 -后端场」笔记创作活动的第6篇笔记。浅析微服务架构，介绍其概念及重点内容。
一.什么是微服务架构
微服务架构风格是一类将单一应用程序作为由众多小型服务构成之套件加以开发的方式，其中各项服务都拥有自己的进程并利用轻量化机制实现通信，如通过REST API或RPC调用。这些服务围绕业务功能建立而成，且凭借自动化部署机制实现独立部署。这些服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
二.为什么要有微服务
传统IT行业软件大多是独立系统的堆砌，存在可扩展性差、模块耦合相互影响、维护成本高的问题。随着系统规模逐渐扩大，代码复杂性越来越高，变得难以维护。而微服务彻底的服务化，每个模块相当于一个单独的项目，可以有效拆分应用，单项目代码量和逻辑复杂度明显降低，更易于开发和维护，实现敏捷开发。由于各服务互相独立，扩展性强，在开发模式上更加灵活，可使用不同的存储方式，易于部署和按需伸缩。实现故障隔离，单模块服务出现问题时只需debug后重启该模块服务即可，不必重启整个项目从而大大节约时间。微服务架构已是目前大多数互联网公司的标准架构。
三.微服务设计原则
1.单一职责原则： 每个微服务只需要实现自己的业务逻辑就可以了，其它的不必考虑。
2.服务自治原则： 每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，不必依赖于其它模块。
3.轻量级通信原则： 首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，以让每个微服务都有足够的独立性，可以不受技术的钳制。
4.接口明确原则： 由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就需要考虑齐全，让接口尽量通用灵活，从而尽量避免其它模块也做调整。
四.微服务架构要素
微服务架构，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
1.服务治理：服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理...
2.可观测性：日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪...
3.安全：身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击...
五.为什么需要service mesh
Service Mesh即服务网格，是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。
Service Mesh专注于服务之间的通信，使用 Service Mesh 可解耦应用程序的重试/超时、监控、追踪和服务发现，无须关心服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
