微服务架构实践感悟

从去年初开始接触微服务架构的一些理念，然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念。 

在微服务架构（Microservices）这个命名被正式提出来之前，我们做系统也有一套著名的思想理论，叫做面向服务架构（SOA）。 

微服务（Microservices）与 面向服务（SOA）架构

You should instead think of microservices as a specific approach for SOA 

上面这段引用自 《Building Microservices》 一书， 

为什么选择微服务架构

首先，当然是该套架构方法有著名的成功经验才导致我去了解与学习它。 

以前我做过的一些大型应用系统，采用模块化的分层式架构，所有的业务逻辑代码最终会打进一个代码库中统一部署。 

微服务架构强调 “微”，但之前有些采用了 SOA 服务化架构思想的系统会搞出很多胖服务来，一点也不微，这依然带来耦合。 

去年对我们应用系统的代码行数做了个统计，有超过 40 万行。 

微服务架构实施

把 1 个应用进程部署到 1 台主机，部署复杂度是 1 x 1 = 1，我们有 200 台主机，那么部署复杂度是 1 x 200 = 200。 

所以实施微服务架构是有很高成本的，只有系统的规模到了一定程度才适合，这也是为什么微服务架构实践诞生于大型互联网公司。 

《Building Microservices》 

1. 自动化文化与环境：自动构建、自动测试、自动部署。

2. 围绕业务能力建模服务，松耦合、高内聚、暴露接口而隐藏实现细节。

3. 服务协作模型：中心化（乐队模型：中心指挥）和去中心化（舞蹈模型：群舞自组织），各自场景不同。

4. 服务交互方式：RPC/REST/WS 技术很多但考虑统一。

5. 服务部署的独立性、失败隔离性、可监控性。

6. 服务流控：降级、限流

7. 服务恢复：多考虑故障发生如何快速恢复而非如何避免发生故障。

8. 服务发布：灰度。

9. 服务部署：一服务一主机模型，需要虚拟化(Hypervisor)、容器化(LXC, Docker)等技术支持，实现硬件资源隔离。

10. 服务配置：中心化配置服务支持

11. 康威定律：任何设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。系统架构的设计符合组织沟通结构取得的收益最大。

12. 伯斯塔尔法则：服务健壮性原则 —— 发送时要保守，接收时要开放。

自进化的微服务架构

早期人们把软件开发和建筑学作类比，Architect 这个词来就源于建筑学，但软件产品和建筑物的性质完全不同。 

而微服务架构思路是不鼓励这种方式的，系统的演进是通过局部的新增、改进或替换微服务来实现的。 

每个历史悠久的城市都有各自不同的味道，城市中的人、时间、技术进步共同决定了今天城市的面貌。 

微服务架构与架构师

架构师的一个角色是技术决策者，技术决策涉及很多权衡取舍（trade-off），而微服务架构给了架构师更多权衡取舍的空间。 

分拆了服务实现的技术决策权，那何时又该适当的介入以避免服务实现不当危及整体系统的安全？ 

架构师工作在抽象和具体两个层面：

• 架构是一项技术工作，技术工作要服务于组织的战略目标。

• 大量的工程实践在每日的工作中不断变化，而渐渐稳定的实践方式被抽象提炼为一系列原则。

• 原则的普及带来整体效率的提升和边际成本的下降，以更有效的支持组织战略目标的快速达成。

• 另外也要确保这些原则不是让开发人员的生活变得更凄惨而是更美好。

• 跟踪新技术发展确保能在合适的时候做出正确的取舍折衷。

• 让开发人员理解某项技术决策的影响和制约以便最有效的执行，甚至在特定情形下深入到代码的实现层面。

文章开头说了，这是我们实施系统的第四个大版本，而之前每一个大版本升级都是一次旧城倒新城的整体搬迁。 

出处：https://blog.csdn.net/mindfloating/article/details/45740573