微服务论文笔记
<p>[TOC]</p>
<h1>微服务论文笔记</h1>
<h2>1.综述类或者提出问题</h2>
<h3>1.1微服务开山之作</h3>
<p><strong>基本信息：</strong> </p>
<ul>
<li>2014|Microservices: a definition of this new architectural term</li>
<li>Lewis J, Fowler M. Microservices: a definition of this new architectural term[J]. Mars, 2014.</li>
</ul>
<p><strong>摘要：</strong> </p>
<pre><code>The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints,and decentralized control of languages and data.</code></pre>
<p><strong>结论：</strong></p>
<pre><code>One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem. (Although this advice isn't ideal, since a good in-process interface is usually not a good service interface.)</code></pre>
<p><strong>可参考的文献：</strong>
持续集成 Fowler M, Foemmel M. Continuous integration[J]. Thought-Works) <a href="http://www">http://www</a>. thoughtworks. com/Continuous Integration. pdf, 2006, 122: 14.
持续交付 Humble J, Farley D. Continuous delivery: reliable software releases through build, test, and deployment automation[M]. Pearson Education, 2010.</p>
<p><strong>笔记：</strong> </p>
<p>首次比较明确的提出微服务的概念和具体的特征以及在实施微服务化中要注意的问题。
<strong><em>微服务的概念</em></strong>：</p>
<pre><code>We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix. But we do think that not enough people consider a microservice architecture and that many software developments would be better off if they used it.</code></pre>
<p>微服务风格并不是新颖的或者创新的说法，他的起源可以追溯到Unix的设计原则，但是我们认为并没有足够的人意识到微服务的好处，并且通过使用微服务风格进行开发可以使软件开发变得更好。</p>
<p><strong><em>单体（monolithic）的问题</em></strong>：</p>
<pre><code>Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.</code></pre>
<p>也就是：扩展问题，不能局部扩展，只能整体扩展；更新周期较慢，要整体重新编译和发布；依赖问题难以选择最合适的架构。</p>
<p><strong><em>具体的characteristics</em></strong>:</p>
<ul>
<li>
<p><strong>Componentization via Services</strong>（通过服务实现组件）
通过服务而不是库实现组件，We define <strong>libraries</strong> as components that are linked into a program and called using in memory function calls, while <strong>services</strong> are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call.
但是就会很难划分边界问题。</p>
</li>
<li>Organized around Business Capabilities</li>
<li>
<p><strong>Products not Projects</strong></p>
<p>Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime. A common inspiration for this is Amazon's notion of "you build, you run it" where a development team takes full responsibility for the software in production. This brings developers into day-to-day contact with how their software behaves in production and increases contact with their users, as they have to take on at least some of the support burden.
单体也可以有这一条，但是服务的粒度越小，服务开发者和使用者建立联系就越容易。</p>
</li>
<li><strong>Smart endpoints and dumb pipes</strong>
Restful 的http调用和RabbitMQ（messaging over a lightweight message bus）</li>
<li><strong>Decentralized Governance</strong>
不同的系统选择不同语言等</li>
<li><strong>Decentralized Data Management</strong>
多模型数据库（Polyglot Persistence），每个微服务最好有自己的数据库，要么是同一个数据库的不同instance,要么是完全不同的数据库系统。
分布式之后不能像单体架构一样通过事物来保证一致性，只能采取最终一致性。具体的解决与业务实践有关，通常情况是允许一定程度的数据不一致为了快速响应，同时有一些逆转进程或者人工去处理不一致数据和错误，这些开销是值得的，因为修复一定程度的不一致错误比保证强一致性花费小。</li>
<li><strong>Infrastructure Automation</strong>
基础设施自动化，持续交付和持续集成，</li>
<li><strong>Design for failure</strong>
快速检测错误和自动恢复</li>
<li><strong>Evolutionary Design</strong></li>
</ul>
<p><strong><em>实施中要注意的问题</em></strong>：
怎么划分，多大，边界怎么区分。</p>
<p>所以分为底层的功能，和上一层的功能，同层不能或者最好不要相互调用。</p>
<h3>1.2可重复使用的自动验收测试 for 微服务的行为驱动开发（Behavior-Driven Development）</h3>
<p><strong>基本信息：</strong> </p>
<ul>
<li>2015|A Reusable Automated Acceptance Testing Architecture for Microservices in Behavior-Driven Development</li>
<li>Rahman M, Gao J. A reusable automated acceptance testing architecture for microservices in behavior-driven development[C]//2015 IEEE Symposium on Service-Oriented System Engineering (SOSE). IEEE, 2015: 321-325.</li>
</ul>
<p><strong>摘要：</strong> </p>
<p>Cloud Computing and Mobile Cloud Computing are reshaping the way applications are being developed and deployed due to their unique needs such as massive scalability, guaranteed fault tolerance, near zero downtime, etc. and also daunting challenges such as security, reliability, continuous deployment and update capability. Microservices architecture, where application is composed of a set of independently deployable services, is increasingly becoming popular due to its capability to address most of these needs and challenges. In recent years, the Behavior-Driven Development (BDD) has become one of the most popular agile software development processes, and frequently used in microservices development. The key to success of BDD is the executable acceptance tests that describe the expected behavior of a feature and its acceptance criteria in the form of scenarios using simple and business people readable syntax. The reusability, auditability, and maintainability become some of the major concerns when BDD test framework is applied for each microservice repository and no previous research addresses these concerns. In this paper, we present a reusable automated acceptance testing architecture to address all these concerns.</p>
<p><strong>结论：</strong></p>
<p><strong>可参考的文献：</strong> </p>
<p><strong>笔记：</strong>
测试；工具
验收测试工具，易于理解的简单的可执行的对预期行为的测试标准,有助于持续交付和持续集成的工具。</p>
<h3>1.3微服务开山之作</h3>
<p><strong>基本信息：</strong> </p>
<ul>
<li>2015|Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud</li>
<li>Villamizar M, Garcés O, Castro H, et al. Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud[C]//Computing Colombian Conference (10CCC), 2015 10th. IEEE, 2015: 583-590.</li>
</ul>
<p><strong>摘要：</strong> </p>
<p><strong>结论：</strong></p>
<p><strong>可参考的文献：</strong> </p>
<p><strong>笔记：</strong> </p>
<p>比较了单体架构和微服务架构部署上云的实践，描述了现有企业在实施微服务过程中可能获得的好处和面临的挑战。
好处：
挑战：</p>
<p>可以使用的材料，不同的架构的部署方式：
传统的单体架构：
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/ff6164bdda7a3fcff2927d7dfa15abe9?showdoc=.jpg" alt="单体" title="单体" />
微服务的项目架构：</p>
<p>微服务部署架构：
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/07bf9fbc35f325fc5efeeb0105368f1d?showdoc=.jpg" alt="微服务" title="微服务" /></p>