单体架构
传统的软件应用为单体架构。尽管也是模块化逻辑，但是最终还是会打包并并部署为单体应用。最主要的原因是太复杂。并且应用扩展性低，可靠性也低。敏捷开发和部署变得无法完成。
治理办法：化繁为简，分而治之。
微服务起源
大家经常谈论的是一个叫SOA（面向服务的架构模式），它和微服务又是什么关系？你可以把微服务想成是SOA的一种实践。
- 小即是美：小的服务代码少，bug也少，易测试，易维护，也更容易不断迭代完善的精致进而美妙。
- 单一职责：一个服务也只需要做好一件事，专注才能做好。
- 尽可能早地创建原型：尽可能早的提供服务API，建立服务契约，达成服务间沟通的一致性约定，至于实现和完善可以慢慢再做。
- 可移植性比效率更重要：服务间的轻量级交互协议在效率和可移植性二者间，首要依然考虑兼容性和移植性。
微服务定义
围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。
微服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活：
- 原子服务
- 独立进程
- 隔离部署
- 去中心化服务治理
缺点：基础设施的建设、复杂度高
微服务不足
经常性可以听到某宝，某b站崩溃等新闻。
- 微服务应用是分布式系统，由此会带来固有的复杂性。开发者不得不使用RPC或者消息传递来实现进程间通信；此外，必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。（GRPC等进程间通信）
- 分区的数据库架构，同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库，从而对开发者提出了更高的要求和挑战。（分布式存储）
- 测试一个基于微服务架构的应用也是很复杂的任务。（微服务测试）
- 服务模块间的依赖，应用的升级有可能会波及多个服务模块的修改。
- 对运维基础设施的挑战比较大。
组件服务化
传统实现组件的方式是通过库（library），库是和应用一起运行在进程中，库的局部变化意味着整个应用的重新部署。
通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。
Go实现一个微服务的模式：
- kit：一个微服务的基础库（框架）
- service：业务代码+ kit依赖+第三方依赖组成的业务微服务
- RPC + message queue：轻量级通讯
本质上等同于，多个微服务组合（compose）完成了一个完整的用户场景（usecase）。
可用性&兼容性
微服务架构采用粗粒度的进程间通信，引入了额外的复杂性和需要处理的新问题，如网络延迟、消息格式、负载均衡和容错，忽略其中任何一点都属于对“分布式计算的误解”。
具体要详细了解以下方面：隔离、超时控制、负载保护、限流、降级、重试、负载均衡。
切记一旦采用微服务架构，那么在服务需要变更的时候我们一定要注意，服务提供者的变更可能会引发消费者的兼容性破坏，时刻保证接口的兼容性。
发送时要保守，接收时要开放。
