这是我参与8月更文挑战的第17天，活动详情查看：8月更文挑战
一、官方定义
- 微服务是由单⼀应⽤程序构成的⼩服务
- 拥有⾃⼰的进程与轻量化处理，服务依业务功能设计
- 以全⾃动的⽅式部署
- 与其他服务使⽤HTTP API通讯
- 同时服务会使⽤最⼩规模的集中管理 （例如Docker）技术，服务可以⽤不同的编程语⾔与数据库等。
二、微服务之前单体应用
优点
- 学习成本低，开发上手快
- 测试、部署、运维比较方便
- 一个人能Carry全场
缺点
- 部署效率低下
- 团队协作开发成本高
- 系统高可用性差
- 线上发布变慢
三、服务化
解决的问题
- 为单体应用的缺点而生
- 解决单体应用膨胀、团队膨胀耦合度高、协作效率低下
概念
把传统的单机应用中通过JAR包依赖产生的本地方法调用，改造成通过RPC接口产生的方法调用。
四、微服务
概念
从2014年开始，随着
- 移动互联网规模的不断扩大
- 敏捷开发
- 持续交互
- 以Docker为代表的容器化技术的成熟
- 以及DevOps⽂化的兴起
- 服务化的思想进⼀步演化
单体演变为今天我们所熟知的微服务，较之于单体化
-
服务拆分粒度更细
微服务可以说是更细维度的服务化，⼩到⼀个⼦模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为⼀个微服务
-
服务独立部署
每个微服务都严格遵循独⽴打包部署的准则，互不影响。⽐如⼀台物理机上可以部署多个Docker实例，每个Docker实例可以部署⼀个微服务的代码
-
服务独立维护
每个微服务都可以交由⼀个⼩团队甚⾄个⼈来开发、测试、发布和运维，并对整个⽣命周期负责
-
服务治理能力要求高
因为拆分为微服务之后，服务的数量变多，因此需要有统⼀的服务治理平台，来对各个服务进⾏管理。
划重点
单体无法解决的业务复杂问题，别指望微服务能帮你解决。
