微服务架构索引

Unix 哲学是：构建小型、单一的应用程序，不管用什么语言，只做一件小而美的事情，用 stdin / stdout 进行通信，并通过管道进行连接。

微服务的概念与发展

在1984年Rob Pike和Brian W.Kernighan发布的 Unix环境编程文章中，使用了BSD的cat -v的例子来认证Unix哲学。这不就正是 James Lewis 和 Martin Fowler 给出的微服务定义。

微服务的概念大概从2013年开始就越来越热，从BAT之类的科技巨头到只有几个人的技术公司，无不在谈论微服务。从Unix环境编程中可以看出，早在半个世纪以前就有了微服务的概念。关于微服务理论介绍的文章太多，口才优秀的人可以给你说上一天，一些大公司也有自己完善的服务治理经验。本位用于总结一直以来对于微服务学习与设计的知识结构。

云原生（Cloud Native）

现在但凡和软件技术有点裙带关系的机构、组织、人士都在谈论各种“云”。还有不少公司以云**、**云、*云*作为公司的名称。抑或着讲服务器迁移到公有云主机厂商的虚拟机，与IT技术沾一点边或者完全不沾边的都可以随时抛出“云应用”、“云计算”、“云数据”等听起来就很高大上的术语持续忽悠着你。

在2013年Matt Stine的Cloud Native概念横空出世。Cloud Native是一系列概念的集合，围绕这一系列标准可以构建从技术架构、到运维管理、再到团队协作的整体性框架。他让基于微服务的应用搭建成为一个标准流程，主要涵盖以下几点内容。

1、微服务（分布式系统）

微服务本身就是一个很具体的概念，简单的说就是：根据性能要求横向拆分为相同功能的负载均衡节点，根据业务要求纵向拆分为不同功能的服务节点。
其次，微服务这个术语下还涵盖了大量概念，也是一个概念的集合，比如：熔断、降级、心跳检查、消息队列、负载均衡、服务注册、服务发现、去中心化、服务通信（RPC、RMI、TCP/IP)、分布式事物（分布式数据库）、分布式存储、分布式同步对象（数据）、缓存穿透、缓存雪崩、业务追踪、统一日志管理、API网关等等。每一个概念背后都是一项功能标准，都有一项或多项技术在支撑。
通常优秀的微服务框架都会实现以上部分功能，同时支撑内部或外部扩展。比如要防止缓存穿透可以自己写一个Bloom Filter（布隆过滤器），或者缓存用Redis（>4.0)并添加过滤器插件，再或者在物理缓存之前再使用Redisson、Hazelcast之类的内存级缓存。
微服务也特指云服务分布式系统的底层技术。比如Dubbo、Spring Cloud以及后面将会提到的Service Mesh等，都会把他们称为微服务框架。

2、康威定律

在使用与架构微服务框架的时候，曾经也思考过这些问题：为什么微服务技术或团队是现在的这种结构？为什么微服务开发需要和敏捷模型配合？为什么使用微服务可以使用不同的语言？而后我找到了一个结论来解释这一切——康威定律。康威定律是微服务技术团队的基础理论，他主要由四个定律组成：

组织的沟通方式通过系统的设计结构来约束：团队的沟通成本呈现指数增长，所以必须把业务/团队边界压缩在固定人员中（5~15人）。
无法完美但能高效：一个系统Bug永远改不完，与其追求无Bug的完美系统，不如追求可允许的修复速度。通过反复验证强化系统。这是敏捷开发、持续集成发布、自动化监控的本源——即使测试覆盖到100%也没法避免不出现bug，但是能在波及面可控的范围内快速解决问题，这样是否更容易接受？
线性团队同质化，业务团队内聚化：如以下示例图
（1）孤岛式应用架构
（2）微服务应用架构

微服务架构

图1）是一个线性团队，前端UI团队、后端中间件团队、DBA团队分工明确层次清晰，然后开发出来的系统也会呈现出对应的样子，因为团队划分的分层架构决定了系统的最终形态。（Communication dictates design 组织沟通方式会通过系统设计表达出来）

图2）是一个以业务划分的团队，每一个团队都有一个完整的从前端UI到后端中间件的“生态”。

康威第三定律告诉我们小团队内部的沟通往往密集而且更加高效，按照这个方式划分的每个子系统自然会逐渐内聚，而团队之间更加倾向以接口沟通耦合性更低。

系统的拆解倾向性。在架构演进的过程中，随着系统规模的增加合理的解决方法都是将复杂的问题拆分。比如数据库并发太高无法承担了，我们一般会执行以下几个步骤：
- 增加Redis、Memcached之类的缓存工具，将原本直接读取物理数据库的一个问题拆解成2个子问题，并分别去解决对应的更多问题。
- 横向按字段拆表，将一些频繁更新的字段独立到独立的表去以关联的形式存在。
- 纵向按照数据业务特征（例如时间段）分区数据。

3、敏捷开发与敏捷基础设施

在康威定律中解释了敏捷开发对于微服务架构的重要性。敏捷开发需要一种流程规范外加一些适合与流程规范的工具，比如我已经在公司里推行了GitLab、Jira之类的敏捷基础设施工具，敏捷工具和方法众多，比如公司的每日站会、卡片式任务和看板等等，这需要根据团队的需要和结构以及团队规模适时调整。

4、DevOps

DevOps（Development、Operations）本身并没有使用指定具体的技术实现，她是一个从软件开发到产品上线发布的流程规范，现实执行中我们拥有有大量的工具提供支持。流程包括：

需求管理。
编码开发，单元测试（Junit、Jest白盒测试）。
QA（黑盒测试）。自动化测试（Server walker）、代码质量监控（Sonar、EsLint）、接口测试（Jmeter、Loadrunner）。
上线发布运维。包括压力测试、多节点的运维管理、以及Cloud Foundry, Kubernetes, Apache YARN, and Apache Mesos,Kubernetes等云平台的使用。

公司现在推广使用CMMI的敏捷模型配合整个流程。