微服务
-
微服务架构下的数据一致性：可靠事件模式
在《微服务架构下的数据一致性：概念及相关模式》中介绍了在微服务中实现数据一致性的三种方式，包括可靠事件模式、业务补偿模式、TCC模式。本文重点说一下可靠事件投递。
-
微服务架构下的数据一致性：概念及相关模式
从2014年开始，微服务逐渐进入大家的视线，被认为是下一代实现信息化的有效手段。设计到系统，其中绕不开的就是数据一致性，从本地事务，到后来的分布式事务，都能够有效的保证数据一致性。但是在微服务架构中，这两种方式都不是最好的选择。
-
微服务架构的陷阱：从单体到分布式单体
你好，我是看山。
前面咱们聊了架构的演进过程，提到单体架构、SOA 架构、微服务架构、无服务架构。整个过程如下图：
目前无服务架构还未成熟，只能满足一些简单场景。所以大家在设计软件架构时，首选还是微服务架构。然后我们又聊了聊如何把单体架构改造为微服务架构，推荐采用绞杀模式，一步一步的实现系统微服务化。
在这个过程中，我们会碰到微服务架构的一个大坑：分布式错觉，即将分布式当成了微服务的全部（充要条件）。
-
关于微服务系统中数据一致性的总结
你好，我是看山。
从单体架构到分布式架构，从巨石架构到微服务架构。系统之间的交互越来越复杂，系统间的数据交互量级也是指数级增长。作为一个系统，我们要保证逻辑的自洽和数据的自洽。
-
除了微服务，我们还有其他选择吗？
你好，我是看山。
前面我们聊了微服务的话题，现在微服务已经是业内通识。但凡系统开发、系统设计，必然采用微服务架构，或者宣称是微服务架构。
但大家有没有想过，微服务架构不是一开始就有的。如果追溯历史，微服务最早在 2005 的云计算博览会，由 Peter Rodgers 博士提出（那时候称为微 Web 服务（Micro-Web-Service））。到了 2014 年，Martin Fowler 与 James Lewis 共同提出微服务（Micron-Service）的概念，算是对概念归纳总结，天下一统。这一年也被称为微服务元年。
那就要问了，在 2014 年之前呢？大家用啥架构？再往前呢？上次互联网大潮的时候，大家又是用啥？我们今天来聊聊这段历史，可能你会对现在习以为常的架构，产生一些新的看法。在架构上，可以有更多的选择。
-
如何实现单体架构到微服务架构的蜕变？
你好，我是看山。
前文我们聊了介绍了单体架构、SOA 架构、微服务架构、无服务架构。如果原来是单体架构，想要切换到微服务架构，该怎么解决呢？本文来聊聊这个话题，解决“什么时候（WHEN）、怎样做（HOW）”。
-
从单体架构到微服务架构
你好，我是看山。
微服务的优势众多，在现在如果有谁没有听过微服务架构，可以从这里了解一下。本文主要聊一聊是否值得花时间将单体架构重构为微服务架构？
-
如何在微服务团队中高效使用 Git 管理代码？
用了 Git 多年，优势和挑战都是深有体会。
话不多说，直接上问题：如何在微服务团队中高效使用 Git 管理代码？
继续不多话，直接上答案：分支管理。
-
微服务中服务注册和发现的可行性方案
你好，我是看山。
在 微服务的基建工作 中提到过，在云原生、微服务时代，如果还是手动修改服务地址，是几乎不可完成的工作，需要一种机制完成自动上报和获取服务地址的支撑组件，可以保障服务的快速上线和下线，这就是服务注册/发现组件。
-
微服务的基建工作
前文说了一下《六字说出微服务的本质》，在文末提到，初创团队不建议直接使用微服务，对于初创团队，最根本的是活下去，而想要使用微服务，需要有很多基础建设。本文就来说下，微服务都需要哪些基础建设。
需要说明的是，下面这些组件，都是基于服务太多这个前提。
微服务的出现是为了研发效能的提升：相同的人数可以处理更多的需求、维护更多的产品，可以更快的交付产品。基于这点，微服务的基础组件，就从解放人力，减少人为失误出发。
下面给出一张微服务基础组件的图片：
-
微服务编程范式
目前很多互联网公司都采用微服务架构，微服务的优点和缺点被反复说到，这里不在重复赘述，只结合工作中的一些实践，说说要用微服务要注意的点，厚颜写做编程范式，其实就是一些具体实践而已。
-
六字说出微服务的本质
我所理解的微服务，就六个字：“高内聚，低耦合”。
没错，就是这个在软件开发过程中被反复提到的六个字，各类设计模式、架构设计、从入门到放弃等各种书中总会提到，从初级到高级到骨灰级程序员、架构师挂在嘴边的也是这六个字。只不过，在微服务概念之前，这六个字被用在类、模块、组件上，微服务则是将它放在服务上。
注：上面是精简版，下面是完整版，看官自便。