微服务
微服务,是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信。
每一个小型服务是围绕着系统中的某一个或一些耦合度高的业务功能进行构建，并且每个服务都维护自身的数据存储、业务开发、自动化测试以及独立的部署机制。
微服务定义第一人
https://martinfowler.com/articles/microservices.html
九大特性
1、服务组件化
每个小服务都是组件，是一个可以独立更换和升级的单元。
2、按业务组织团队
每一个服务都是针对特定业务的“全栈”实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的职能。按业务划分可以有效减少服务内部修改所产生的内耗，团队边界可以变得更为清晰。
3、做“产品”的态度
每个服务的维护团队都要以做产品的方式和态度，对服务的整个生命周期负责。既要有过程又要有结果。
4、粗粒度通信协议
尽可能的轻量级通信，选择HTTP协议的API或者RCP形式，还有在轻量级消息总线上传递消息，降低交互依赖成本。
5、服务独立技术选型
各个服务组件可以针对其不同业务特点选择不同的技术平台。
6、服务独立管理数据库
每一个服务独自管理其自有的数据库，尽可能存储于不同的数据库实例。服务间进行“无事物”调用，追求数据最终一致性，建立补偿机制。
7、持续交付的自动化
构建持续交付平台来支撑整个开发实施过程，自动化测试和自动化部署。
8、服务调用容错设计
为了快速检测故障源和自动恢复服务，要实现服务的监控和日志记录，并建立闭环的反馈机制。
9、演进式构建过程
架构师要以演进的方式进行系统的微服务化构建，将一些经常变动或有一定时间效应的内容进行微服务处理，并逐渐将原来系统按模块进行拆分，而稳定不太变化的模块就形成了一个核心微服务。
微服务架构
优点：
- 易于开发和维护
- 单个微服务启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩扩展
缺点：
- 运维要求较高
- 分布式带来的复杂性
- 接口调整成本高
- 重复劳动存在
设计原则：
- 单一职责
- 服务自治
- 轻量级通信
- 粒度划分
中台战略思考
微服务化的后期首选要考虑到服务网的复杂性，研发团队如何面对错综复杂的服务场景，要进行服务层级划分，数据基础服务、中间间服务、应用层服务、安全监控辅助服务等等。持续交付和批量编排要考虑容器化方案，devops思想下的k8s运用等等。微服务化进程最终都会经过“中台”阶段，逐步走必然会到，急不得。