最近在看 《微服务设计(Sam Newman 著)》 这本书。作者是 ThoughtWorks 的 Sam Newman。这本书中包括很多业界是用案例,比如 Netflix 和 亚马逊。有兴趣的话大家一起看看讨论一下。😄
P.S 这本书比较偏理论,另外还有一本中国人写的书,《微服务架构与实践,王磊著,电子工业出版社》 。这个人同样也是 ThoughtWorks 的,两个人的观点不谋而合,依然是便理论的东西。
Cloud Native Go - 基于 Go 和 React 的 web 云服务构建指南
这本书是我最近在翻译的,将由 电子工业出版社 出版,本书根据实际案例教你如何构建一个 web 微服务,是实践为服务架构的很好的参考。查看本书介绍。
微服务(Microservices)这个词比较新颖,但是其实这种架构设计理念早就有了。微服务是一种分布式架构设计理念,为了推动细粒度服务的使用,这些服务要能协同工作,每个服务都有自己的生命周期。一个微服务就是一个独立的实体,可以独立的部署在 PAAS 平台上,也可以作为一个独立的进程在主机中运行。服务之间通过 API 访问,修改一个服务不会影响其它服务。
微服务的好处有很多,包括:
可以说微服务架构师 SOA 的一种,但是目前的大多数 SOA 做的都不好,在通信协议的选择
、第三方中间件的选择
、服务力度如何划分
方面做的都不够好。
微服务与 SOA 的共同点
架构师(Architect)在英文中和建筑师是同一个词,他们之间也有很多相同之处,架构师构建的是软件,而建筑师构建的是建筑。
终于看到了我翻译的Cloud Native Go第 14 章中引用的这本书的原话了。
软件的需求变更是来的那么快来的那么直接,不像建筑那样可以在设计好后按照设计图纸一步步的去建设。
架构师应该关心的是什么呢?
protocol buffer
呢,还是使用RESTful API
,还是使用Java RMI
,这个才是架构师需要关注的问题,至于服务内部究竟使用什么,那就看开发人员自己了,架构师更需要关注系统的边界和分区。以MusicCorp这家公司的服务为例子讲解。
服务建模的两个指导原则:
使用限定上下文(一个由显示边界限定的特定指责)的方法将服务拆分,比如 MusicCorp 的服务可以拆分为:
他们都不需要知道各自的具体实现,只要给它们提供特定的输入就会有你想要的产出。
过早的将一个系统划分成微服务的代价非常高,尤其是在面对新领域时,将一个已有的代码库划分成微服务会比葱头开始建设微服务要简单的多。
使用共享数据库,为用户创建好接口,可以使用 RPC(protocol buffer、thrift)或者 REST。服务端和客户端消息格式可以用 Json 或 XML。当然每种技术都有各自的适用场景,结合自己的业务选择。
微服务的协作方式是什么样的呢?基于事件的异步通信,使用消息中间件来实现事件发布和消费者接收机制。比如用 Kafka 或 RabbitMQ。
分解巨大无比没人感动的单块系统,首先要做的是理清代码库,找到接缝。
分解系统带来的好处:
这一块跟传统服务的部署并没有太大的不同,无非是微服务的短平快,加快了 CI(持续集成)的速度。如果将微服务打包为 docker 镜像,使用 Jenkins、ansible、puppet 等技术来部署微服务可以实现部署自动和效率的显著提高。
该书的后面还讲了测试、监控、安全、康威定律、最后还上升到人本,给予广大的软件开发人员强烈的人文关怀,可见提倡架构师要融入团队,最一个代码架构师和结对编程的作者是多么博爱❤️。
该书的核心部分是第 11 章规模化微服务,为将在下篇中来探讨一下。
最后更新于 2024/12/12