一 、微服务概览

微服务———SOA的一种实践。

• 小即是美:小的服务代码少,bug也少,易测试,易维护,也更容易不断迭代完善的精致进而美妙。
• 单一职责:一个服务也只需要做好一件事,专注才能做好。
• 尽可能早地创建原型:尽可能早的提供服务AP,建立服务契约,达成服务间沟通的一致性约定,至于实现和完善可以慢慢再做。
• 可移植性比效率更重要:服务间的轻量级交互协议在效率和可移植性二者间,首要依然考虑兼容性和移植性。

1. 微服务定义

• 原子服务
• 独立进程
• 隔离部署
• 去中心化服务治理

缺点：

• 基础设施的建设、复杂度高

2. 微服务不足

• 微服务应用是分布式系统，由此会带来固有的复杂性。开发者不得不使用 RPC 或者消息传递，来实现进程间通信；此外，必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。
• 分区的数据库架构，同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库，从而对开发者提出了更高的要求和挑战。
• 测试一个基于微服务架构的应用也是很复杂的任务。
• 服务模块间的依赖，应用的升级有可能会波及多个服务模块的修改。
• 对运维基础设施的挑战比较大。

3. 按业务组织服务

大前端(移动/Web) =》 网关接入 =》业务服务 =》平台服务 =》基础设施(PaaS/Saas) 开发团队对软件在生产环境的运行负全部责任

4.去中心化

• 数据去中心化
• 治理去中心化
• 技术去中心化

5.基础设施自动化

• CICD：Gitlab + Gitlab Hooks + k8s
• Testing：测试环境、单元测试、API自动化测试
• 在线运行时：k8s，以及一系列 Prometheus、ELK、Conrtol Panle

6.可用性 & 兼容性设计

• 隔离
• 超时控制
• 负载保护
• 限流
• 降级
• 重试
• 负载均衡

Be conservative in what you send, be liberal in what you accept. 发送时要保守，接收时要开放。按照伯斯塔尔法则的思想来设计和实现服务时，发送的数据要更保守，意味着最小化的传送必要的信息，接收时更开放意味着要最大限度的容忍冗余数据，保证兼容性。

二 、微服务设计

1. API Gateway

2. Mircoservice 划分

• Business Capability 由公司内部不同部门提供的职能。例如客户服务部门提供客户服务的职能，财务部门提供财务相关的职能。
• Bounded Context 限界上下文是 DDD 中用来划分不同业务边界的元素，这里业务边界的含义是“解决不同业务问题”的问题域和对应的解决方案域，为了解决某种类型的业务问题，贴近领域知识，也就是业务。

CQRS，将应用程序分为两部分：命令端和查询端。命令端处理程序创建，更新和删除请求，并在数据更改时发出事件。查询端通过针对一个或多个物化视图执行查询来处理查询，这些物化视图通过订阅数据更改时发出的事件流而保持最新。 在稿件服务演进过程中，我们发现围绕着创作稿件、审核稿件、最终发布稿件有大量的逻辑揉在一块，其中稿件本身的状态也有非常多种，但是最终前台用户只关注稿件能否查看，我们依赖稿件数据库 binlog 以及订阅 binlog 的中间件 canal，将我们的稿件结果发布到消息队列 kafka 中，最终消费数据独立组建一个稿件查阅结果数据库，并对外提供一个独立查询服务，来拆分复杂架构和业务。