01微服务概览

微服务起源

早期有一种面向服务的架构模式，也就是SOA–可以将微服务理解成轻量级SOA的一种最佳实践。

从单一的“全家桶”架构，其拥有单一的数据库，需要考虑非常清晰的模块划分以及依赖等等。通过化繁为简、分而治之，将原来“全家桶”架构演进到分布式的一个微服务的模型。不同的服务存在很强的隔离性和独立部署性。

特点：

• 小即是美：小的服务代码量少，bug也会少，易于测试，也更容易不断迭代完善进而趋近完美。

• 单一职责：一个服务也只需要做好一件事情，专注才能做得更好。----借鉴《代码整洁之道》

• 尽可能早的定义接口原型：尽可能早的提供服务API，达成服务间的沟通一致性的约定，至于实现和完善可以后面慢慢再做，起先甚至可以做一些mock。

• 可移植性高于效率重要性：服务间的轻量级交互在效率和可移植性之间，首要考虑兼容性和可移植性。—在不同的场景下需要选择不同的语言进行开发，若选择兼容性更强的框架，则不同语言之间进行交互会变得easy，否则维护将会变得更加复杂。

微服务定义

首先其需要围绕业务功能构建，服务只需要关注单一的业务，服务间采用轻量级的通信机制（此通讯机制应该是相互兼容的，各种语言都是可以打通的，如HTTP restful等，也易于实现），可以独立部署，以及能够使用不能的编程语言和存储方案。微服务架构通过业务拆分实现服务组件化（把一个服务当做组件来拆分），通过组件之间的组合来完成一个系统的开发（可理解为面向业务场景的一种API或功能），业务单一的服务组件又能够单独的部署，这样整个系统都会变得很灵活

优点

• 原子服务

  意味着一个微服务关注的单一的业务场景和单一的业务。其API一定是围绕这个单一的业务单元来构建的。

• 独立进程

  独立的进行部署和交互。

• 隔离部署

  例如巨石部署的时候倾向于部署在一个强大的物理机上，假设3台48核，虽然能抗住流量需求，但是若出现一台机器宕机之后，影响的可能有1/3的服务，微服务流量小、业务单一，所以可以部署成一个4核，整体可能需要40台物理机（或者docker），那么若有一台宕机之后，对整个系统服务影响其实是没有太大的。

• 去中心化服务治理

  服务与服务之间通信更简单，也就是说A服务直连B服务，节点之间也是RPC直连通信的。但是像服务发现等场景就需要一个集中化的服务发现组件。

缺点：

• 对基础设施建设的高度依赖性。

  入力当从巨石应用变为多个小应用之后，应用管理的复杂度会变高，监控设施和体系 、日志查看。技术复杂度会变高、数据一致性的复杂度变高。

组件服务化

实现一个微服务需要组件服务化。

传统的组件通常是提供各种各样的代码库或者SDK，库和应用是一起运行在进程中的，一个库的局部变化会导致整个应用重新进行交付（指巨石架构的一个完整应用）。

在通过服务实现组件化之后，应用被拆分成一系列的服务运行在不同的进程中，单一服务的局部变化只需要重新部署对应的服务进程即可。

用Go实现一个微服务：

• kit：一个微服务的基础库（框架）
• service：业务代码+kit依赖+第三方依赖组成的业务微服务
• RPC + message queue：轻量级通信

本质上等同于把多个微服务组合compose完成了一个完整的用户场景(usecase)

去中心化场景

每个服务面临的业务场景不同，可以针对性的选择合适的技术解决方案(可能存在多语言)。但是需要注意避免过度的多样化，需要结合实际场景来选择。否则每个服务都用不同语言的技术栈实现(则很难构建一个kit库/基础库、多套SDK)，则维护成本就会大大变高。

• 数据去中心化

  每个人独占实例、独占数据库、独占cache，一个超大数据库解决所有

• 治理去中心化

  所有流量热点的地方，避免一个集中式的东西来处理、做分发或做流量处理

• 技术去中心化

  不一定需要绑定到某一种语言，满足轻量级、兼容级

每个服务独自拥有自身的数据存储设施，不像传统应用共享一个缓存和数据库，从隔离性上考虑这个服务能够独立部署交互，并且其使用的资源也是隔离的，避免相互干扰

基础设施自动化

自动化包含测试、部署。

• CICD
• Testing：测试环境、单元测试、API自动化测试
• 在线运行时：kubernets等

若有错误，请提出斧正。谢谢