微服务设计

软件的本质困难在于软件本身的复杂性。 我们头脑中最多同时注意5～9件事，因此对付复杂性的方法自然而然就是——分而治之。 数据库，模块化，面向对象，MVC，SOA（Service-Oriented-Architecture，面向服务的架构）都是在做抽象，都是在做分而治之，都有同一个指导纲领: 高内聚，低耦合。它们的主要差别在于实现方式和关注的粒度不同。其核心都是分解复杂度，使得每小块软件的复杂度能被我们完全控制。 微服务架构可以看做是SOA的一种特定方法，它并不是银弹。 它只是通过以一个个微服务的方式，来拆分整个软件的复杂度，各个微服务间通过清晰可控的信息交流，来完成整个软件的功能。 但是，服务分离后，所引入的一系列分布式问题，我们仍然无法回避。 但所幸的是，服务分离后，各个服务之间的极致的松耦合使得重用和移植变得非常容易。很容易集成一些第三方的服务，或搭建在不同平台之上（例如:公有云，私有云，混合云，物理集群）。  而且，现在云厂商都在试图提供一整套的微服务解决方案，使得开发人员不需要去解决分布式所引入的种种问题，只需要关注于业务逻辑本身。云厂商帮你解决分布式的一致性，可用性，隔离性，弹性伸缩；为你提供安全保护，通信协议，开发工具，集成测试；提供持续集成，持续交付，灰度发布的能力；提供完善的监控，可选的容灾策略，以及运营数据的查询与显示；还有一系列支持用户自定义的接口，可以方便的定制化以及和其他云服务无缝隙兼容的能力。 因此，我觉得微服务是一个高度软件工程化的，并且和云结合到一起才能落地的产物。而微服务的一种极致形式就是无服务器函数，真的只需要开发人员关注服务本身。

这个星期主要是在整理自己对于微服务设计的一些思考，也回顾了Sam的这本书，根据作者的一些建议去改进了原本模式中的一些问题，比如微服务不要直接去操纵数据库，而把这个权限交给一个人专门去做这个事情的服务来处理等等。经过优化后觉得整个后端的模式确实变得更加清晰了。倘若你们的产品也有考虑切换到微服务模式，这本书还是值得一看的。

微服务这个词，已经出现很久了，但是一直没有去了解一下，连最基本的概念都不清楚，然后百度了一下，了解了一些相关的概念，然后就找到了这本书，就大致看了一下，有些章节没有看，因为要看的技术很多，我目前的目标是形成自己的一个技术知识体系，所以不会在具体的技术上花费太多的时间，没有那么多精力去从前往后认真的看，有个大概的了解就差不多了，将来如果涉及到这方面的工作再去细看。 下面是微服务的一些大的原则。 第1点围绕业务概念建模，微服务，比较难的一点是划分上下文边界，也就是，这个微服务，他需要实现什么业务？另外一个，建模要围绕着业务来而不是技术。 第2点，自动化的文化。由于把单个系统拆分成多个微服务，那么多个微服务的部署以及之间的协同、测试就会比较复杂。如果每次部署发布版本，都是通过手工的方式去做这些检查的话那么效率就太低了，所以在开发微服务之前，为微服务提供配套的工具和流水线是非常有必要的。 第3点，隐藏内部实现细节。服务和服务之间通过对外接口来实现协作即可，而服务内部的实现不应该暴露出去，以防服务和服务之间发生耦合。 第4点是一切去中心化。应该使用单机单服务模式。如果把多个微服务部署在一台机器上，如果服务对于机器的环境有所依赖的话，那么，部署在一台机器上就有可能存在兼容性问题。 第5点，独立部署。你可以更改单个服务，然后把它部署到环境里，并且无需联动地部署其他的服务，这应该是常态。 第6点，隔离失败，当其中一个服务出现异常时不能造成连级异常，所以对服务要考虑超时的处理，断路器和舱壁等。 第7点是高度可观察，提供日志监控和诊断，可以方便快速的定位问题。

微服务不是免费的午餐，更不是银弹，如果你想要得到一条通用准则，那么微服务是一个错误的选择。你需要面对所有分布式系统需要面对的复杂性。尽管后面用很多的篇幅来讲解如何管理分布式系统，但它仍然是一个很难的问题。如果你过去的经验更多的是关于单块系统，那么为了得到上述那些微服务的好处，你需要在部署、测试和监控等方面做很多的工作。你还需要考虑如何扩展系统，并且保证它们的弹性。如果你发现，还需要处理类似分布式事务或者与CAP相关的问题，也不要感到惊讶！ 每个公司、组织及系统都不一样。微服务是否适合你，或者说你能够在多大程度上采用微服务，取决于很多因素。

非常好的一本书，思想和理念讲的非常好，其中里面的一些东西还需要自己私下近行学习和查阅相关资料，毕竟自己知识眼界太低，我们要把微服务的理念执行下去，毕竟是未来的主流。给作者点赞，需要在重温一把！温故而知新，学而不思则罔，思而不学则殆

这本书cool哦！介绍的微服务框架，整理如下以供参考： 1.服务注册中心service register，比如，zookeeper。 springcloud， netflix，Eureka。 2.服务调用方式, RPC, rest API。服务间通过REST api相互通信。 3.服务网关。gateway，负责分发路由，负载均衡策略，鉴权等。客户端不会直接request服务端，要经过网关层！ 4.断路器。很主要，类似熔断机制。 5.分布式配置config。 6.服务追踪，也是链路追踪。 7.消息总线bus。 8.数据流cloud stream。 9.批量任务cloud task. 以上不是业务拆分，是微服务框架分布式分层解耦后的架构层级。对于不同业务拆分的规则是尽可能做到最大限度的松耦合。书中有提到模块间的界限划分！但是我还不太理解！他还没有结合具体业务场景相关，进行深入探讨！

《微服务设计》Building Microservices 在人工智能/AI之外，微服务是另一个火热的领域。微服务就是一些小而自治的服务，其主要好处包括技术异构性、弹性、扩展、简化部署、与组织结构相匹配和可组合性等。微服务架构是SOA (Service-Oriented Architecture)的进一步发展，是一系列原则，例如围绕业务建模、去中心化、自动化等等，也是与一系列的技术紧密相关的包括云计算、DevOps、持续集成(Continuous Integration)/持续部署(Continuous Delivery)、容器(Container)等。 在之前的项目中，当时虽然还没有微服务的概念，但我们为了优化系统尝试了许多这个方向的事情，包括对功能的解耦合、异步架构、使用REST/JSON接口、各种缓存从CDN到varnish到memcache 、SSO(Single Sign On)、自动化测试、自动化部署、虚拟化/公有云、监控、安全等等等等。遇到了很多问题，取得了一些成绩，学到了很多东西。 简而言之，微服务设计是好东西，但也会带来很多挑战。IT技术的变化是日新月异的，微服务设计的这些思想理念和技术是一个旅程，关键是如何持续地改进和演变系统。而这本书作为微服务的入门书籍，是超级推荐的。

企业的技术主管，在构建技术架构时必须拥有微服务设计的技能，而要设计出一套卓越的微服务架构，仍需充足的知识积累和实践历练。此书勾勒了一幅极佳的蓝图，但具体实施仍需依据实际状况来做出抉择。 编程语言、微服务架构框架、服务之间的调用机制、分布式事务处理、一致性保障策略、负载均衡技术、部署策略……

微服务其实是服务撞上天花板的回应。在某种程度上，传统的单体应用架构没有伸缩性，数据库变得太大了，有太多的代码行，无法快速添加功能和特性，但微服务架构也带来了一系列难以解决的新问题，特别是在日志、监视、测试和调试应用程序方面。评估是否使用微服务应该考虑应用程序的生命周期，团队的人数，还有业务的模块是否需要拆分

偏向理论，最后引用书中的一段话:学会拥抱演进式架构的概念，在这种概念下，系统会在你学到一些新东西之后扩展和变化。不要去想大爆炸式的重写，取而代之的是随着时间的推移，逐步对系统进行一系列更改，这样做可以保持系统的灵活性。