点击查看目录

最近在看 《微服务设计（Sam Newman 著）》 这本书。作者是 ThoughtWorks 的 Sam Newman。这本书中包括很多业界是用案例，比如 Netflix 和 亚马逊。有兴趣的话大家一起看看讨论一下。😄

P.S 这本书比较偏理论，另外还有一本中国人写的书，《微服务架构与实践，王磊著，电子工业出版社》 。这个人同样也是 ThoughtWorks 的，两个人的观点不谋而合，依然是便理论的东西。

Cloud Native Go - 基于 Go 和 React 的 web 云服务构建指南

这本书是我最近在翻译的，将由 电子工业出版社 出版，本书根据实际案例教你如何构建一个 web 微服务，是实践为服务架构的很好的参考。查看本书介绍 。

1.微服务初探

什么是微服务？

微服务（Microservices）这个词比较新颖，但是其实这种架构设计理念早就有了。微服务是一种分布式架构设计理念，为了推动细粒度服务的使用，这些服务要能协同工作，每个服务都有自己的生命周期。一个微服务就是一个独立的实体，可以独立的部署在 PAAS 平台上，也可以作为一个独立的进程在主机中运行。服务之间通过 API 访问，修改一个服务不会影响其它服务。

微服务的好处

微服务的好处有很多，包括：

• 帮助你更快的采用新技术
• 解决技术异构的问题，因为是用 API 网络通信，可以使用不同的语言和技术开发不同的服务
• 增强系统弹性，服务的边界比较清晰，便于故障处理
• 方便扩展，比如使用容器技术，可以很方便的一次性启动很多个微服务
• 方便部署，因为微服务之间彼此独立，所以能够独立的部署单个服务而不影响其它服务，如果部署失败的话还可以回滚
• 别忘了康威定律，微服务可以很好契合解决组织架构问题
• 可重用，可随意组合
• 便于维护，可以随时重写服务，不必担心历史遗留问题

与面向服务架构 SOA 的关系

可以说微服务架构师 SOA 的一种，但是目前的大多数 SOA 做的都不好，在通信协议的选择、第三方中间件的选择、服务力度如何划分方面做的都不够好。

微服务与 SOA 的共同点

• 都使用共享库，比如可重用的代码库
• 模块化，比如 Java 中的 OSGI(Open Source Gateway Initiative)、Erlang 中的模块化

2.架构师的职责

架构师应该关心是什么

架构师（Architect）在英文中和建筑师是同一个词，他们之间也有很多相同之处，架构师构建的是软件，而建筑师构建的是建筑。

终于看到了我翻译的Cloud Native Go第 14 章中引用的这本书的原话了。

软件的需求变更是来的那么快来的那么直接，不像建筑那样可以在设计好后按照设计图纸一步步的去建设。

架构师应该关心的是什么呢？

• 保证系统适合开发人员在上面工作
• 关注服务之间的交互，不需要过于关注各个服务内部发生的事情，比如服务之间互相调用的接口，是使用protocol buffer呢，还是使用RESTful API，还是使用Java RMI，这个才是架构师需要关注的问题，至于服务内部究竟使用什么，那就看开发人员自己了，架构师更需要关注系统的边界和分区。
• 架构师应该与团队在一起，结对编程 🤓🤓 了解普通工作，知道普通的工作是什么样子，做一个代码架构师 😂

架构师应该做什么

• 提供原则指导实践，比如 Heroku 的12 因素法则 用来指导 SAAS 应用架构一样，微服务架构设计也要有一套原则。
• 提供要求标准，通过日志功能和监控对服务进行集中式管理，明确接口标准，提供安全性建议。
• 代码治理。为开发人员提供范例和服务代码模板。
• 解决技术债务。
• 集中治理和领导。维持良好的团队关系，当团队跑偏的时候及时纠正。

3.服务建模

以MusicCorp这家公司的服务为例子讲解。

服务建模的两个指导原则：

• 高内聚：关键是找出问题的边界，把相关的问题放在同一个服务中。
• 松耦合：修改一个服务不需要修改另一个。

使用限定上下文（一个由显示边界限定的特定指责）的方法将服务拆分，比如 MusicCorp 的服务可以拆分为：

• 财务部门
• 仓库

他们都不需要知道各自的具体实现，只要给它们提供特定的输入就会有你想要的产出。

过早的将一个系统划分成微服务的代价非常高，尤其是在面对新领域时，将一个已有的代码库划分成微服务会比葱头开始建设微服务要简单的多。

4.集成

使用共享数据库，为用户创建好接口，可以使用 RPC（protocol buffer、thrift）或者 REST。服务端和客户端消息格式可以用 Json 或 XML。当然每种技术都有各自的适用场景，结合自己的业务选择。

微服务的协作方式是什么样的呢？基于事件的异步通信，使用消息中间件来实现事件发布和消费者接收机制。比如用 Kafka 或 RabbitMQ。

5.分解单块系统

分解巨大无比没人感动的单块系统，首先要做的是理清代码库，找到接缝。

分解系统带来的好处：

• 加快以后系统开发速度
• 划清了团队结构（又是康威定律）
• 增加安全审计功能后，保障安全性
• 利于开展新技术

6. 部署

这一块跟传统服务的部署并没有太大的不同，无非是微服务的短平快，加快了 CI（持续集成）的速度。如果将微服务打包为 docker 镜像，使用 Jenkins、ansible、puppet 等技术来部署微服务可以实现部署自动和效率的显著提高。

其它

该书的后面还讲了测试、监控、安全、康威定律、最后还上升到人本，给予广大的软件开发人员强烈的人文关怀，可见提倡架构师要融入团队，最一个代码架构师和结对编程的作者是多么博爱❤️。

该书的核心部分是第 11 章规模化微服务，为将在下篇中来探讨一下。