hic染色体构想_了解微服务：从构想到起点

hic染色体构想

by Michael Douglass

迈克尔·道格拉斯(Michael Douglass)

了解微服务：从构想到起点 (Understanding Microservices: From Idea To Starting Line)

Over the last two months, I have invested most of my free time learning the complete ins-and-outs of what the microservices architecture really entails. After much reading, note taking, white-boarding, and many hours writing, I feel like I have achieved a level of understanding such that I am ready to take the first step. Allow me to share what I have learned from start to finish.

在过去的两个月中，我将大部分的业余时间用于学习微服务架构真正需要的全部内容。 经过大量阅读，记笔记，白板和大量时间的写作之后，我觉得自己已经达到了一定的理解水平，因此我准备迈出第一步。 请允许我分享我从头到尾学到的东西。

微服务：高级，这是什么？ (Microservices: High-Level, What Are They?)

Microservices is an architecture in which different component pieces of a software design are created and housed as individual, isolated services. Each is deployed separately and they communicate through well-defined network-based interfaces. Microservices are intended to be “small” (loosely defined) and kept to a single bounded context.

微服务是一种体系结构，在该体系结构中，软件设计的不同组成部分被创建并作为单独的隔离服务存放。 每个都单独部署，并且它们通过定义良好的基于​​网络的接口进行通信。 微服务旨在“小”(松散定义)，并保持在单个有限的上下文中。

There are many benefits to microservices. Because of their isolation and strict requirement to communicate through well-defined interfaces, microservices prevent quick and dirty solutions often found in monoliths. These hacks inside of a monolith result in a loss of cohesion and an increase in coupling — two primary causes of complexity.

微服务有很多好处。 由于微服务的隔离性和通过定义良好的接口进行通信的严格要求，微服务可防止通常在整体中发现的快速而肮脏的解决方案。 整体内部的这些hack导致内聚力的丧失和耦合的增加，这是导致复杂性的两个主要原因。

Many will argue that you can maintain this behavior in a monolith. In reality, because it is easy and because there are too few architects working in our code bases, monoliths typically fall due to this very failing.

许多人会争辩说，您可以保持这种行为。 实际上，因为这很容易，并且因为在我们的代码库中工作的架构师太少，所以由于这种失败而导致整体程序通常掉线。

Complexity comes from low cohesion and high coupling. Microservices provides the structure to keep that at bay.

复杂性来自低内聚和高耦合。 微服务提供了阻止这种情况的结构。

This benefit cannot be overstated. Because we keep the complexity monster at bay, development on systems a decade old can continue to move along at the speeds of development when the system was brand new.

不能夸大这一好处。 因为我们避免了复杂性的怪兽，所以在十年之久的系统上的开发可以继续以全新系统的开发速度前进。

Time and again, the complexity brought on by loose cohesion and tight coupling has been the cause of slow development on older projects. Cohesion and coupling is traditionally the technical debt grasping onto our feet, slowing us down. Pile enough of it up over the years, and you will be slogging through it.

一次又一次地，松散的内聚力和紧密的耦合所带来的复杂性一直是旧项目开发缓慢的原因。 传统上，凝聚力和耦合是我们脚上的技术债务，使我们放慢了脚步。 这些年来堆积了足够多的内容，您将一路过关斩将。

When the services are written with them in mind, and the infrastructure provides it, other benefits can include horizontal scalability, testability, reliability, observability, replaceability, and language independence.

当记住这些服务并由基础结构提供服务时，其他好处可能包括水平可伸缩性，可测试性，可靠性，可观察性，可替换性和语言独立性。

The downside for microservices is that to achieve these benefits, you must provide an underlying infrastructure which supports them. Without that support, you can easily find yourself with an unreliable and opaque system — or you find yourself reinventing the reliability wheel in every single service. This is a great lead-in to the next section…

微服务的缺点是要获得这些好处，您必须提供支持它们的基础架构。 没有这种支持，您将很容易发现自己的系统不可靠且不透明，或者您发现自己在每项服务中都重新发明了可靠性。 这是下一节的很好的介绍...

微服务：高级要求(宏) (Microservices: High-Level Requirements (The Macro))

An environment which supports microservices fundamentally needs a set of baseline requirements to ensure some level of sanity. If you are going to run microservices, your organization must be willing to bear the overhead of starting and supporting them. The overhead will not be insignificant. It will take time and money to do microservices well.

支持微服务的环境从根本上需要一系列基准要求，以确保一定程度的完整性。 如果要运行微服务，您的组织必须愿意承担启动和支持微服务的开销。 开销将不算什么。 做好微服务将需要时间和金钱。

A successful microservices architecture must have an internal committee or group responsible for defining the macro-architecture — this will define what infrastructure will be provided for the development and operation of microservices along with policies which all microservices must adhere. This committee must be the strongest of your development staff, and it may even be one or more people who do not even work for you yet.

成功的微服务架构必须有一个内部委员会或小组来负责定义宏架构 -这将定义为微服务的开发和运营提供哪些基础设施以及所有微服务必须遵守的政策。 该委员会必须是您开发人员中最强大的，甚至可能是一个或多个甚至还没有为您工作的人。

The macro-architecture is one part provided infrastructure and one part policy requirements for all microservices.

宏体系结构是为所有微服务提供的基础结构和策略要求的一部分。

Each organization’s macro-architecture will be unique. Each area listed below is completely open to negotiation around where to draw the line for your group: you can provide the teams with a fixed service or library of code to provide the required functionality. You can either mandate its use, or make its use optional. You could simply provide acceptance criteria to which a microservice must adhere, but provide no implemented library or service to help fulfill the requirement. Lastly, you could choose to do and require nothing for any given category.

每个组织的宏架构都是唯一的。 下面列出的每个区域都完全可以就组划界的位置进行协商：您可以为团队提供固定的服务或代码库，以提供所需的功能。 您可以强制使用它，也可以使其可选。 您可以简单地提供微服务必须遵守的接受标准，但是不提供任何已实现的库或服务来帮助满足需求。 最后，您可以选择执行任何操作，并且不需要任何给定类别。

Choose wisely what you leave out of your macro-architecture. For every choice you allow the individual development teams to make, you must be willing to live with differing decisions, implementations, and operational behaviors.

明智地选择从宏体系结构中遗漏的内容。 对于您允许各个开发团队做出的每一个选择，您都必须乐于接受不同的决策，实施和操作行为。

You are the committee, and it is always best when people in the organization make these decisions — therefore, I cannot provide you with a baked manifesto.

您是委员会，组织中的人员做出这些决定时始终是最好的选择—因此，我无法向您提供一份明确的宣言。

As you are starting out, it is also important to keep this macro-architecture documentation open to change and receptive to the needs of the teams and the business. Now, let us turn to looking at the different categories for which macro-architecture decisions must be made.

在开始之初，保持此宏体系结构文档开放以进行更改并接受团队和业务的需求也很重要。 现在，让我们看一下必须针对其做出宏观体系结构决策的不同类别。

持续集成/持续交付 (Continuous Integration/Continuous Delivery)

Core to the concept of microservices is the ability to build and execute tests in a very fast manner. Every commit to the microservice should result in a tested build. Once the tests pass and the build system is happy, a push button or an automatic deployment to production is the next important aspect. Cutting time to deploy allows rapid iteration and enables any number of good coding practices.

微服务概念的核心是以非常快速的方式构建和执行测试的能力。 对微服务的每次提交都应生成经过测试的构建。 一旦测试通过并且构建系统满意，下一个重要方面就是按钮或自动部署到生产中。 缩短部署时间可实现快速迭代并启用许多良好的编码实践。

This is an easy one to fulfill these days. There are any number of build systems which provide access to pipeline builds. Team City. Bamboo. Jenkins with Blue Ocean. Try them out and pick one. For the most part, the feature sets are fairly standard across the leaders of the pack.

这些天来这很容易实现。 有许多构建系统可提供对管道构建的访问。 团队之城 。 竹子 。 詹金斯与“蓝色海洋” 。 试试看，选一个。 在大多数情况下，功能集在整个产品组合的领导者中都是相当标准的。

An organization should strive for consistency in how services are built and deployed. Therefore, the macro-architecture should define the build tool and pipeline processes. The teams should have a voice in the conversation leading to the choice, but they should not be allowed to go rogue on this one.

组织应努力在构建和部署服务的方式上保持一致性。 因此，宏架构应定义构建工具和管道流程。 团队应该在对话中表达自己的意见，以使他们做出选择，但不应让他们对此无礼。

虚拟机/容器 (Virtual Machines/Containers)

Hand in hand with CI/CD is the ability to spin up a number of instances of a specific version of your service. The macro-architecture needs to consider how teams will manage doing this for both development, test, staging, and production environments.

与CI / CD携手合作是能够启动服务特定版本的许多实例的功能。 宏架构需要考虑团队将如何在开发，测试，登台和生产环境中进行管理。

For staging and production you are often faced with the desire to do canary roll-outs with trivial roll-back in the event of a failure. Having common infrastructure, policies, and procedures around how you package and deploy a service will make this easier for development and operations.

对于登台和生产，您经常会遇到在发生故障的情况下进行金丝雀小规模回滚的需求。 围绕如何打包和部署服务具有通用的基础结构，策略和过程，将使开发和操作变得更加容易。

Load monitoring and instance control management should also be considered and facilitated by this portion of the macro-architecture. How to determine when more instances of a given service are needed, and having a consistent way to put them into production will be critical to long term success.

宏体系结构的这一部分也应考虑并促进负载监视和实例控制管理。 如何确定何时需要更多给定服务实例，以及采用一致的方式将其投入生产对于长期成功至关重要。

记录中 (Logging)

It is vital to monitor your microservices in production. To do so efficiently, you need to enable quick location of disparate information. This implies that the macro-architecture should strongly consider including the following:

监视生产中的微服务至关重要。 为了有效地做到这一点，您需要快速定位不同的信息。 这意味着宏体系结构应强烈考虑包括以下内容：

1. A logging service for centralized logging. This can be the Elastic Stack, Slack, Graylog, and others of their ilk. You want a logging stack that includes a strong parser/visualizer because you are going to be dealing with a bunch of data. Part of your infrastructure can be one of these services, and a guarantee that each host in the environment will be configured to transfer log files on behalf of each service.

   集中式日志记录服务。 这可以是Elastic Stack ， Slack ， Graylog以及其他类似的东西 。 您需要一个包含强大的解析器/可视化器的日志记录堆栈，因为您将要处理大量数据。 基础架构的一部分可以是这些服务之一，并且可以保证环境中的每个主机都将被配置为代表每个服务传输日志文件。

2. Definition of trace IDs to enable the location of all logs across all microservices handling a single external request. The concept here is that, for every external request coming into your microservices, you generate a unique ID, and that ID is passed to any internal microservices calls used to handle that request. Thus through a search for a single trace ID, you can find all microservices calls resulting from a single external access.
   定义跟踪ID，以实现在处理单个外部请求的所有微服务中所有日志的位置。 这里的概念是，对于进入您的微服务的每个外部请求，您都会生成一个唯一的ID，并将该ID传递给用于处理该请求的任何内部微服务调用。 因此，通过搜索单个跟踪ID，您可以找到由单个外部访问导致的所有微服务调用。
3. Base formatting requirements for server, service, instance, timestamp and trace IDs.
   服务器，服务，实例，时间戳和跟踪ID的基本格式要求。

监控方式 (Monitoring)

This is another “must provide” for the macro-architecture. Microservices will each need to decide on the best metrics to measure and monitor which will ensure individual success, but the macro-architecture will have specific instrumentation it will need from every service in order to provide oversight of the overall health of the system. Some macro-level data points include:

这是宏体系结构的另一个“必须提供”。 每个微服务都需要决定最佳的度量标准来衡量和监视，以确保个人成功，但是宏体系结构将具有每种服务都需要的特定工具，以监督系统的整体运行状况。 一些宏级别的数据点包括：

• The volume of messages, failures, successes, retries, and drops.
  消息，失败，成功，重试和删除的数量。
• The latency of requests.
  请求的延迟。
• The ratio of received messages to sent messages.
  已接收消息与已发送消息的比率。
• Status of circuit breakers.
  断路器的状态。
• And more. Much, much more.
  和更多。 更多，更多。

Instrumentation is one area where The Tao of Microservices really shines, and I highly recommend it for a good understanding of the breadth and depth of monitoring in microservices.

仪器仪表是微服务之道真正发挥作用的领域，我强烈建议您使用它，以更好地了解微服务监视的广度和深度。

服务注册和位置 (Service Registration & Location)

This is often overlooked when a microservices architecture is small because a few microservices can always find each other relatively easily. However, as time goes on and the number of microservices grows, the configuration necessary to connect everyone together statically becomes too constraining and eventually error prone. Many solutions can be had including DNS and configuration services (etc, etc.)

当微服务架构较小时，这通常会被忽略，因为一些微服务始终可以相对容易地找到彼此。 但是，随着时间的流逝以及微服务数量的增加，将每个人静态连接在一起所需的配置变得过于严格，最终容易出错。 可以有许多解决方案，包括DNS和配置服务(等)。

The macro-architecture of your microservices environment must define how this is done — even if the first iteration is /etc/services.yaml deployed and synchronized to all hosts.

您的微服务环境的宏体系结构必须定义此操作的完成方式-即使第一次迭代是/etc/services.yaml部署并同步到所有主机。

This is not something that the development teams on individual services should set in place — it should be ubiquitous and managed from the macro-architecture level.

这不是每个服务的开发团队都应该设置的东西，它应该是无处不在的，并且应该从宏观体系结构级别进行管理。

There are many, existing open source projects attempting to solve this problem including some of the service mesh software listed at the end of this article.

有许多尝试解决此问题的现有开源项目，包括本文结尾处列出的一些服务网格软件。

沟通机制 (Communication Mechanisms)

Microservices should have some level of control in how they implement their interfaces. Both the network level protocol and the application level protocol should provide some level of flexibility. Using Google Protocol Buffers over raw TCP could be just as available as using JSON RPC over HTTPS. That said, the macro-architecture should provide some guidance, some restrictions, and maybe even some infrastructure to help facilitate communication.

微服务应该在如何实现其接口方面具有一定程度的控制。 网络级协议和应用程序级协议都应提供一定程度的灵活性。 在原始TCP上使用Google协议缓冲区可能与在HTTPS上使用JSON RPC一样可用。 也就是说，宏体系结构应该提供一些指导，一些限制，甚至可能提供一些基础结构来帮助促进通信。

If a microservices infrastructure is going to work together in a common domain name space under HTTPS URIs, then you will want standardization around the naming and routing. The requests should have a common and consistent method by which ingress user requests as well as service-to-service requests are authenticated, authorized, and routed.

如果微服务基础架构要在HTTPS URI下的通用域名空间中协同工作，那么您将需要围绕命名和路由进行标准化。 这些请求应该具有一种通用且一致的方法，通过该方法可以对入口用户请求以及“服务到服务”请求进行身份验证，授权和路由。

A microservices infrastructure which wants to permit the use of messaging as a communication device should consider providing an operations-managed messaging bus. This enables rapid development and deployment of services without teams needing to first focus on starting and then long-term managing a messaging service. It also fosters decoupling of services which want to communicate through the messaging service — if I have to know which messaging queuing service each service uses, I am growing more coupled.

希望允许使用消息传递作为通信设备的微服务基础结构应该考虑提供操作管理的消息传递总线。 这样就可以快速开发和部署服务，而无需团队首先专注于启动然后长期管理消息传递服务。 它还促进了要通过消息传递服务进行通信的服务的解耦-如果我必须知道每个服务使用的消息传递排队服务，则我将变得更加耦合。

Providing the infrastructure for your messaging layer also enables you to provide message routing to your services — something which can greatly enhance the flexibility of your macro-architecture. The ability to route requests through different versions of a service based on various criteria affords a lot of flexibility and helps to further maintain decoupling.

为消息传递层提供基础结构还可以使您向服务提供消息路由，这可以极大地增强宏体系结构的灵活性。 基于各种标准通过服务的不同版本路由请求的能力提供了很大的灵活性，并有助于进一步保持解耦。

负载平衡和弹性 (Load Balancing & Resiliency)

Microservices are often used in environments where scaling and availability are expected. Traditionally, network devices provide load balancing functionality. But in a microservices environment, it is more typical to see this moved into the software layer of the macro-architecture’s infrastructure.

微服务通常用于需要扩展和可用性的环境中。 传统上，网络设备提供负载平衡功能。 但是在微服务环境中，更常见的是将其转移到宏体系结构的基础架构的软件层中。

Code through which services communicate can utilize service location to discover all network locations of a given service, and it can then directly perform load balancing logic right there at the distributed edge.

服务通过其进行通信的代码可以利用服务位置来发现给定服务的所有网络位置，然后可以直接在分布式边缘上执行负载平衡逻辑。

Resiliency means remaining stable even in the face of errors. Retries, deadlines, default behaviors, caching behaviors, and queuing are a few of the ways microservices provide resiliency.

弹性意味着即使遇到错误也能保持稳定。 重试，截止时间，默认行为，缓存行为和排队是微服务提供弹性的几种方式。

Just like load balancing, some part of resiliency is a perfect match for the infrastructure to handle at the edge— such a retries and circuit breaking (automatic error responses for services exceeding a failure threshold in the recent past).

就像负载平衡一样，弹性的某些部分非常适合基础结构在边缘进行处理，例如重试和断路(最近的服务自动错误响应超过故障阈值)。

However, the individual service should consider what resiliency role it should play internally. For example, an account signup system, where losing a signup equates to losing money, should take ownership of ensuring that every signup goes through — even if it means a delayed creation that results in an email to the account owner once successful. Internal queuing and management of pending signups may be best managed directly by this mission-critical service.

但是，单个服务应考虑其在内部扮演的弹性角色。 例如，一个帐户注册系统(其中失去注册等同于赔钱)应拥有确保每次注册都通过的所有权-即使这意味着创建时间过长，一旦成功就会向帐户所有者发送电子邮件。 通过此任务关键型服务，最好直接管理内部排队和未决注册的管理。

持久性：数据库，NoSQL等 (Persistence: Database, NoSQL, and so on)

A microservices architecture completely isolates each microservice from the rest. Ultimately, they understand their own data storage needs best, and should, therefore, be individually encouraged to control their own destiny as it relates to data persistence. However, you still do not need to allow the wild, wild west to rule the day, and thus the macro-architecture should provide guidance (sometimes heavy-handed).

微服务架构将每个微服务与其他服务完全隔离。 最终，他们最了解自己的数据存储需求，因此应鼓励他们控制与数据持久性有关的自己的命运。 但是，您仍然不需要让狂野的西部来统治这一天，因此宏架构应该提供指导(有时是费力的)。

Here are some options you can look to include in the macro-architecture:

您可以查看以下包含在宏体系结构中的一些选项：

1. One or more data storage services including an SQL based relational database and a NoSQL storage system. These provided data storage services should include built-in backups. A microservice should utilize unique credentials with limited access to a schema restricted to only that microservice’s data. In this scheme, the operations team providing the storage service are responsible for its operation.
   一种或多种数据存储服务，包括基于SQL的关系数据库和NoSQL存储系统。 这些提供的数据存储服务应包括内置备份。 微服务应利用唯一的凭证，并且只能访问仅限于该微服务数据的模式。 在此方案中，提供存储服务的运营团队负责其运营。
2. If you allow the microservices to bring their own persistence, you should have strict policy requirements for backups and disaster recovery. Think about off-site backups, recovery time, fail-over time, and so on. In this model, the development team is responsible for the operation of the storage service.
   如果允许微服务带来自己的持久性，则对备份和灾难恢复应该有严格的策略要求。 考虑场外备份，恢复时间，故障转移时间等。 在此模型中，开发团队负责存储服务的操作。

You should absolutely, without a doubt, refuse to permit the traditional “open access, one database to rule them all” mentality which permeates the world of monolith development. If your disparate services are able to communicate through the database, unexpected coupling will occur. Services must only have access to its own data stores, and cross-service communication must be maintained through their well-defined network interfaces.

毫无疑问，您绝对应该拒绝允许渗透到整体开发世界中的传统“开放访问，一个数据库来统治所有人”的心态。 如果您不同的服务能够通过数据库进行通信，则将发生意外的耦合。 服务只能访问其自己的数据存储，并且跨服务通信必须通过其定义良好的网络接口进行维护。

I recently stumbled upon extremely nasty coupling of the database sort in an older monolith. The complexity was immediately obvious and my sadness grew exponentially.

最近，我偶然发现了一个较旧的整体数据库中极其恶劣的数据库类型耦合。 复杂性立即显而易见，我的悲伤成倍增加。

安全 (Security)

Your services need to know to whom they are talking (authentication) and what data and operations are permitted (authorization) to said identity. There are several potential concepts here:

您的服务需要知道与谁谈话(身份验证)，以及允许对所述身份进行哪些数据和操作(授权)。 这里有几个潜在的概念：

• Let the IP network protect the services — if you run all of your microservices on a protected network, and you want to transfer trust to your development staff to not abuse access, then this might work for you. Keep in mind that a breach of a single service implies full access to all other services.
  让IP网络保护服务-如果您在受保护的网络上运行所有微服务，并且希望将信任转移给开发人员以不滥用访问权限，那么这可能对您有用。 请记住，违反一项服务就意味着可以完全访问所有其他服务。
• Service-level authentication — shared keys or certificate-based authentication allows a called service to validate a calling service. You will need a secure way to distribute and update keys and certificates to keep this secure. Use a Key Management Service.
  服务级别身份验证-共享密钥或基于证书的身份验证允许被叫服务验证主叫服务。 您将需要一种安全的方式来分发和更新密钥和证书，以确保此安全。 使用密钥管理服务。
• User-level authentication — not only are services talking to services, but they are quite often talking on behalf of a user or even directly to a user. There must be a means of authenticating and authorizing the user-level credential to the resource at hand.
  用户级身份验证-服务不仅在与服务对话，而且经常代表用户甚至直接与用户对话。 必须有一种对现有资源进行身份验证和授权的用户级凭据的方法。

Start simple — this is an area that can break an organization out the gate, and it is probably best to start simple. You likely already have a few different services that talk to one another, and you are likely using some IP access-control lists to protect them. Start simple, add to the complexity as a natural evolution of the system.

从简单开始-这是一个可以使组织脱颖而出的领域，最好是从简单开始。 您可能已经有一些可以互相通信的不同服务，并且您可能正在使用一些IP访问控制列表来保护它们。 从简单开始，随着系统的自然发展而增加复杂性。

修正案X-保留权力 (Amendment X — Reserved Powers)

The powers not delegated to the infrastructure by the macro-architecture are reserved to the individual services respectively, or to the developers of such.

宏体系结构未委派给基础结构的权限分别保留给各个服务或此类服务的开发人员。

Do not underestimate the power of this statement. If the macro-architecture does not cover an aspect of the environment, the developers are free to choose and choose they will. The more teams you have, the more solutions you will find yourself maintaining. Therefore, do two things with your macro-architecture:

不要小看这句话的力量。 如果宏体系结构没有涵盖环境的某个方面，则开发人员可以自由选择并选择他们愿意的。 您拥有的团队越多，您将找到更多的解决方案。 因此，对您的宏体系结构做两件事：

1. Consider very carefully what you leave out. If you follow the “start small” principle, you are likely not going to be providing a lot of ready-made infrastructures to cover the details of the macro-architecture. This is perfectly acceptable. However, you can still provide guidance and requirements around those areas in order to minimize the chaos.
   非常仔细地考虑您遗漏的内容。 如果您遵循“从小做起”的原则，则可能不会提供大量现成的基础架构来覆盖宏架构的细节。 这是完全可以接受的。 但是，您仍然可以围绕这些领域提供指导和要求，以最大程度地减少混乱。
2. Iterate rapidly. As the first few services come online, meet and discuss the entire macro-architecture. What is working? What is not working? What do you need to change now? (How very agile of me!) Do this on a regular basis. You will hear this again in a few moments.
   快速迭代。 随着前几项服务上线，请见面并讨论整个宏体系结构。 有什么用？ 什么不起作用？ 您现在需要更改什么？ (我有多敏捷！)定期执行此操作。 稍后您会再次听到。

谁应该使用微服务？ (Who Should Use Microservices?)

Everyone should use Microservices.

每个人都应该使用微服务。

There, I said it, and I will defend it relentlessly. Yes, I realize that there are plenty of people, likely far smarter and more learned than I am, who state, philosophically: “If you are not Netflix and you are not Amazon, then the overhead of using a microservices architecture is going to drown you.”

我在那说了，我将不懈地捍卫它。 是的，我意识到有很多人从哲学上说：“如果您不是Netflix而且您不是Amazon，那么使用微服务架构的开销将被淹没。您。”

The notion that I have to be Netflix or Amazon to make productive use of a microservices architecture brings, and I hope you quote me on this, one word to mind: Hogwash.

我必须是Netflix或Amazon才能有效利用微服务架构的想法带来了，我希望您在此引用我一个想法：Hogwash。

一切都与尺寸有关... (It’s All About Size…)

The reality here is that the smaller your organization, the smaller your needs for a fully fledged microservices architecture. However, there is no reason to abandon the entire movement and leaving behind the benefits these very smart people have realized, even when you are a small shop with small services.

这里的现实是，组织越小，对成熟的微服务架构的需求就越小。 但是，即使您是一家提供小服务的小商店，也没有理由放弃整个运动并留下这些非常聪明的人已经意识到的好处。

Your initial microservices macro-architecture conversations need to focus on precisely what you need to get started and then figure out how to get that into place. Build some services, observe their behaviors, and learn from what is and is not working for you.

您最初的微服务宏体系结构对话需要准确地专注于您需要入门的内容，然后弄清楚如何实现它。 建立一些服务，观察其行为，并从对您有用和不有用的内容中学习。

Reconvene your microservices macro-architecture committee and use your new found experience along with your healthy reading and growing understanding of the industry-wide ecosystem to determine what the next evolution of your macro-architecture must be. Rinse and repeat. Iterate.

重新召集您的微服务宏架构委员会，并利用您新发现的经验以及对整个行业生态系统的健康阅读和不断了解，来确定宏架构的下一个发展方向。 冲洗并重复。 重复。

Your microservices macro-architecture should continuously evolve right alongside the every day, iterative development you already do.

您的微服务宏体系结构应该与您已经做过的每天迭代开发一起不断发展。

We live and breath this “agile” world of iterative design and development. There is very little reason that it should not apply to the infrastructure surrounding our services. Even if you never actually realize a fully idealized microservices architecture, but you have these architecture conversations and continually add small iterations of infrastructure and macro-architecture — you will have reaped many of the benefits over time.

我们生活和呼吸这个迭代设计和开发的“敏捷”世界。 几乎没有理由不将其应用于我们服务周围的基础架构。 即使您从未真正实现过完全理想化的微服务体系结构，但是您进行了这些体系结构对话并不断添加基础结构和宏体系结构的小迭代-随着时间的推移，您将获得许多好处。

Most importantly, because you focus each iteration of the microservices macro-architecture from a position of what you need at-the-time, you will have spent your time on the most valuable components of your organization.

最重要的是，由于您将微服务宏体系结构的每个迭代都从您当时需要的位置集中起来，因此您将把时间花在组织中最有价值的组件上。

Perhaps you started with a healthy CI/CD pipeline that took over 85% of your existing monolithic development jobs. Dividends! Next, you standardize your deployments into docker images and provide tooling around launching, migrating, and rolling back new versions. Dividends! Then add in consistent logging and monitoring, and you start to visualize and report on messaging flows through your systems. Dividends! Now as you are adding new services, you realize that the coupling of services talking directly to one another is holding you back, and you add a messaging service to your infrastructure and begin moving some functionality to event-based triggers. Dividends!

也许您是从一条健康的CI / CD管道开始的，该管道占据了您现有的整体开发工作的85％以上。 红利！ 接下来，您将部署标准化到Docker映像中，并提供有关启动，迁移和回滚新版本的工具。 红利！ 然后添加一致的日志记录和监视，然后开始可视化并报告通过系统的消息流。 红利！ 现在，当您添加新服务时，您已经意识到直接相互交谈的服务耦合阻碍了您的工作，并且将消息传递服务添加到基础结构中，并开始将某些功能转移到基于事件的触发器上。 红利！

I do not believe you need to be Amazon or Netflix to reap the benefits of a microservices architecture. In some cases, you can use the knowledge of how these architectures work inside of a single monolith, and the dividends can be quite rich indeed.

我认为您不必成为Amazon或Netflix即可获得微服务架构的好处。 在某些情况下，您可以使用有关这些体系结构如何在单个整体中工作的知识，确实可以带来很多好处。

From the start, or years after the monolith begins to fail under its own weight, you can use the knowledge of how to separate services to shore it up and make it more stable. A monolith which is internally designed with good separation between services makes an easy target for microservices when success demands more from it. (Just realize that it takes architects to maintain the integrity of a monolith, and beyond the start of a system it will be difficult to achieve long-term.)

从一开始，即整体式服务器在其自身的重量下开始失效的几年后，您就可以使用有关如何分离服务的知识来支撑它并使其更稳定。 内部设计的内部服务之间具有良好的隔离性，当成功需要更多服务时，它很容易成为微服务的目标。 (只要意识到，架构师需要保持整体的完整性，而在系统启动之初，就很难长期实现。)

宏架构基础架构 (The Macro-Architecture Infrastructure)

One of my key questions, when I began this journey, was how I would provide any desired, baseline infrastructure to the developers of services within my organization. My reading lead me to understand three primary methods:

当我开始这一旅程时，我的主要问题之一是如何为组织内的服务开发人员提供任何所需的基准基础结构。 通过阅读，我了解了三种主要方法：

1. Run systems which provide the services along with documentation on the proper use thereof. An example here is to provide a CI/CD system and guidelines on how to configure your service’s pipeline. This is perhaps the simplest of the two, because we are all very used to having this type of prepared infrastructure managed by an operations team.
   运行提供服务以及正确使用文档的系统。 这里的一个示例是提供CI / CD系统和有关如何配置服务管道的指南。 这也许是两者中最简单的一个，因为我们都非常习惯由运营团队来管理这种准备好的基础架构。
2. Provide code which developers can bake into their systems to perform the desired functionality. An example here would be a shared library that can be used to perform service location and load balancing. This restricts the ability for teams to choose their own language, but the benefit of not creating this infrastructure multiple times can outweigh that cost.
   提供开发人员可以烘焙到其系统中以执行所需功能的代码。 这里的一个示例是可以用于执行服务定位和负载平衡的共享库。 这限制了团队选择自己的语言的能力，但是不多次创建此基础结构的好处可能会超过该成本。
3. If language independence is truly desired for your services, the infrastructure components can be placed in a sidecar implementation which runs as a secondary process alongside each service. The sidecar then represents the service, and provide access to other services, in the infrastructure. Sidecars appear to be more prevalent in the industry than I had first thought possible.
   如果您的服务确实需要语言独立性，则可以将基础结构组件放置在sidecar实现中，该实现作为每个服务旁边的辅助过程运行。 然后，边车代表服务，并提供对基础结构中其他服务的访问。 在我看来，Sidecar在行业中的流行程度比我最初想象的要大。

脱离开放源代码的基础架构 (Off The Open-Source-Shelf Infrastructure)

There are a plethora of options available to get yourself started with a microservices macro-architecture. You would be extremely remiss to not consider the options as a part of your initial macro-architecture conversations. Some of these existing infrastructure pieces make getting started quite easy — further supporting my stance that everybody can benefit from this.

有很多选项可让您开始使用微服务宏体系结构。 如果您不考虑这些选项作为您最初的宏体系结构对话的一部分，那将是您的极大遗憾。 这些现有的基础架构部分使入门变得非常容易-进一步支持了我的立场，即每个人都可以从中受益。

Some of the more cohesive off-the-shelf infrastructure projects are referred to as service meshes. Service meshes provide a control plane (clustered management of the service mesh proxies and other macro services) and a data plane (the proxy services through which your services communicate). They typically operate in the form of a sidecar proxy which provides the microservices networking functionality out of the box. Using one of these can give you a head start on the bulk of the functionality — and for many people, they may be more than you will ever need.

一些更具凝聚力的现成基础架构项目被称为服务网格。 服务网格提供控制平面(服务网格代理和其他宏服务的集群管理)和数据平面(服务通过其进行通信的代理服务)。 它们通常以Sidecar代理的形式运行，该代理提供了开箱即用的微服务联网功能。 使用其中之一可以让您抢先使用大部分功能-对于许多人来说，它们可能比您需要的更多。

These projects are all relatively young, and they are going to impose limitations on your environment that you might not have otherwise chosen. However, they are designed and developed by people who know microservices very well, and you can both use their insights into what works and save a lot of time not recreating the technologies yourself.

这些项目都是相对较年轻的项目，它们将对您的环境施加某些您可能没有选择的限制。 但是，它们是由非常了解微服务的人设计和开发的，您既可以利用他们的见解来了解有效的方法，又可以节省大量时间而不自行创建技术。

Here are a few that I have found and done at least a moderate amount of investigation into (these descriptions are surface-reading only — see the respective sites for more information!).

以下是一些我发现并至少进行了中度调查的内容(这些说明仅是表面阅读，请参阅相应的站点以获取更多信息！)。

网飞 (Netflix)

Netflix is hot on the scene with microservices architecture, and they have open sourced much of their base run-time services and libraries. They work in the JVM, and include Eureka for service discovery, Archaius for distributed configuration, Ribbon for resilient and intelligent inter-process and service communication, Hystrix for latency and fault tolerance at run-time, and Prana as a sidecar for non-JVM based services.

Netflix凭借微服务架构而备受关注，并且它们已经开源了许多基本运行时服务和库。 它们在JVM中工作，包括用于服务发现的Eureka ，用于分布式配置的Archaius ，用于弹性和智能的进程间和服务通信的Ribbon ，用于在运行时进行延迟和容错的Hystrix ，以及用于非JVM的辅助工具Prana。基础服务。

The Netflix-provided infrastructure pieces may be too big for a smaller shop. But if you are working in the JRE already, adding support for Eureka, Ribbon, and Hystrix can quickly grant you many benefits with potentially small amounts of investment.

Netflix提供的基础设施对于较小的商店来说可能太大了。 但是，如果您已经在JRE中工作，那么增加对Eureka，Ribbon和Hystrix的支持可以通过潜在的少量投资Swift为您带来许多好处。

春云 (Spring Cloud)

Spring has long been a central place to go for frameworks enabling quick and easy JVM-based software development. Their Spring Cloud specialized section includes integrations with a lot of cloud infrastructure, including the above mentioned Netflix libraries among many others. If you are going to go the JVM route, it will be worth your while to get to know Spring Cloud.

长期以来，Spring一直是框架的中心，这些框架可实现基于JVM的快速，便捷的软件开发。 他们的Spring Cloud专业部分包括与许多云基础架构的集成，其中包括上述Netflix库以及其他许多库。 如果您打算走JVM路线，那么花点时间来了解Spring Cloud是值得的。

Linkerd (服务网格) (Linkerd (Service Mesh))

This service mesh, written by Buoyant, was released to the open source world early in 2016. It runs as a sidecar and acts as a proxy between your services. It provides you with: load balancing, circuit breaking, service discovery, dynamic request routing, HTTP proxy integration, retries and deadlines, TLS, transparent proxying, distributed tracing, and instrumentation. Protocol support includes HTTP/1.x, HTTP/2, gRPC, and anything TCP-based.

该服务网格由Buoyant编写，已于2016年初发布到开源世界。它作为辅助工具运行，并充当服务之间的代理。 它为您提供：负载平衡，电路中断，服务发现，动态请求路由，HTTP代理集成，重试和截止日期，TLS，透明代理，分布式跟踪和检测。 协议支持包括HTTP / 1.x，HTTP / 2，gRPC以及任何基于TCP的协议。

Linkerd tries to not tie you down to any one technology — it supports running locally, in Docker, in Kubernetes, in DC/OS, in Amazon ECS, and more.

Linkerd尝试不让您束缚任何一项技术，它支持在Docker，Kubernetes，DC / OS，Amazon ECS等本地运行。

As a sidecar application, it can be run once per service or once per host — so if you run multiple services per host, you can save on process overhead with Linkerd. They boast a couple of very well known names on their used by list.

作为Sidecar应用程序，它可以每个服务运行一次，也可以每个主机运行一次—因此，如果每个主机运行多个服务，则可以使用Linkerd节省进程开销。 他们在列表中使用了几个非常知名的名称。

Interestingly, you can integrate Linkerd with Istio (covered below). I am unclear what the benefits of this are, but a surface reading says there may be something there.

有趣的是，您可以将Linkerd与Istio集成(如下所述)。 我尚不清楚这样做有什么好处，但从表面上看，可能存在某些问题。

导管 (服务网格) (Conduit (Service Mesh))

In December 2017, almost two years after Linkerd, Buoyant released another service mesh specifically for Kubernetes clusters. They took their lessons learned, and are creating Conduit with the intention of being an extremely lightweight service mesh.

2017年12月，也就是Linkerd推出后将近两年，Buoyant发布了另一个专门用于Kubernetes集群的服务网格。 他们吸取了教训，并正在创建Conduit，旨在成为一个非常轻便的服务网格。

The Conduit tooling works in tandem with the Kubernetes tooling to inject itself into your cluster. Once injected, most of the work happens behind the scenes through proxying and the use of standard Kubernetes service naming schemes. It claims good end-to-end visibility, but I do not see good screenshots of that, and have not yet tested it out myself.

Conduit工具与Kubernetes工具协同工作，以将其自身注入您的集群。 一旦注入，大部分工作将通过代理和使用标准的Kubernetes服务命名方案在后台进行。 它声称具有良好的端到端可见性，但是我看不到很好的屏幕截图，也没有自己进行测试。

A big caution here is the Alpha status and the extremely new creation— February 2018. They have published a Roadmap to Production with an insight of where they are going. For now, I would test drive it and keep this one on the “to watch” list.

这里要特别注意的是Alpha的状态和极其新颖的产品-2018年2月。他们发布了生产路线图，对他们的前进方向有深刻见解。 现在，我将对其进行测试并将其保留在“要观看”列表中。

Istio (服务网格) (Istio (Service Mesh))

Istio is a service mesh which came to us in May of 2017. Internally they are using Envoy (covered next). They have instructions for deploying on top of Kubernetes, Nomad, Consul, and Eureka.

Istio是一个服务网格，于2017年5月问世。在内部，他们使用Envoy(将在接下来介绍)。 他们有在Kubernetes，Nomad，Consul和Eureka上进行部署的说明。

As a sidecar, it provides automatic load balancing, fault injecting, traffic shaping, timeouts, circuit breaking, mirroring, and access controls for HTTP, gRPC, WebSocket, and TCP traffic. Ingress and Egress traffic is afforded the same feature set. Automatic metrics, logs, and traces are available quickly through included visualization tools. They also enable infrastructure level, run-time routing of messages based on content and meta information about the request.

作为辅助工具，它为HTTP，gRPC，WebSocket和TCP流量提供自动负载平衡，故障注入，流量整形，超时，断路，镜像和访问控制。 入口和出口流量具有相同的功能集。 通过随附的可视化工具可以快速获得自动指标，日志和跟踪。 它们还支持基础结构级别，基于有关请求的内容和元信息的消息的运行时路由。

The downside is it is very young and restricted to specific deployment environments — though there is some documentation that may help you deploy in other environments using manual methods.

缺点是它还很年轻，并且仅限于特定的部署环境-尽管有一些文档可以帮助您使用手动方法在其他环境中进行部署。

Istio uses iptables to transparently proxy network connections through the sidecar — in the Kubernetes world this is truly transparent to you, but in other environments, you are involved in making that work. (It honestly looks like most of these mesh services are using iptables’ transparent proxy mechanisms to hook their sidecars into your applications.)

Istio使用iptables通过sidecar透明地代理网络连接-在Kubernetes的世界中，这对您而言确实是透明的，但是在其他环境中，您需要参与这项工作。 (老实说，这些网状服务中的大多数似乎都在使用iptables的透明代理机制将它们的附属工具挂接到应用程序中。)

On the upside, the security feature set feels mature and well thought out. All egress connections are, by default, denied until explicitly permitted — and that is refreshing! You protect your services within your mesh the same way you protect it at the ingress and Egress — nice!

从好的方面来说，安全功能集感到很成熟并且经过深思熟虑。 默认情况下，所有出口连接均被拒绝，直到明确允许为止，这令人耳目一新！ 您可以像保护入口和出口一样保护网格中的服务-太好了！

The out-of-the-box visualization of your services as a network diagram and various per-service metrics provides you immediate observability into your environment. Large-scale deployments will likely need to own moving this into larger deployments, but as a getting started environment it is very nice.

服务的现成可视化网络图和各种每项服务指标为您提供了对环境的即时观察性。 大规模部署可能需要自己将其迁移到更大的部署中，但是作为入门环境，它非常好。

特使 (数据平面) (Envoy (Data Plane))

Originally built by Lyft, but released after Linkerd in 2016, this one has the appearance of being the most mature. It boasts very large companies on its “Used By” list. It is written in C++ and is intended to be run as a sidecar like the rest. It was built to support running a single service or application as well as supporting a service mesh architecture.

最初由Lyft建造，但在Linkerd之后于2016年发布，外观看起来是最成熟的。 它在“ Used By”列表中拥有非常大的公司。 它是用C ++编写的，旨在像其他工具一样作为辅助工具运行。 它旨在支持运行单个服务或应用程序以及支持服务网格体系结构。

That said, Envoy is not a full-service mesh as it only provides the data plane and you must manage the Envoy processes yourself or use Istio (which, by default, uses the Envoy proxy).

就是说，Envoy并不是一个提供全方位服务的网格，因为它仅提供数据平面，您必须自己管理Envoy进程或使用Istio(默认情况下使用Envoy代理)。

A quick look through the documentation shows a healthy list of features, including filters, service discovery, health checking, load balancing, circuit breaking, rate limiting, TLS, statistics, tracing, logging, and much more. Connection type supported include HTTPS, TCP, and Websockets.

快速浏览该文档可以看到功能完整的列表，包括过滤器，服务发现，运行状况检查，负载平衡，电路中断，速率限制，TLS，统计信息，跟踪，日志记录等等。 支持的连接类型包括HTTPS，TCP和Websocket。

I am impressed with Envoy from the window dressing, and given Istio’s use of Envoy, I will most likely experience it through a test drive of Istio first (and will only look at Envoy alone if I feel there is something Istio is hiding or preventing me from utilizing fully).

橱窗装饰给Envoy留下了深刻的印象，并且考虑到Istio对Envoy的使用，我很可能会先通过Istio的试驾体验一下(并且只有在我感觉到Istio隐藏或阻止了我时，才单独看Envoy)。充分利用)。

快速开始-兴奋无比！ (Jump Start — Excitement Abounds!)

I am extremely excited to sit down with each of these existing technologies and give them a thorough run-through. With the sheer amount of functionality they already provide, I would be woefully remiss to not understand them and include them as the basis for whatever microservices macro-architecture I support in my organization.

我非常高兴能够接受这些现有技术中的每一项，并为它们提供了详尽的介绍。 鉴于它们已经提供的大量功能，我很遗憾不了解它们，并将它们作为我在组织中支持的任何微服务宏体系结构的基础。

Building all of this functionality from scratch, and not taking advantage of the great work already done by so many fine, brilliant individuals would be a crime. I would rather my organization spend its time on the services and functionality that makes them money — or, if we must extend more functionality to the macro-architecture infrastructure, spend that time contributing back to one of these projects.

从头开始构建所有这些功能，而没有利用这么多优秀而有才华的人已经完成的出色工作将是犯罪。 我宁愿我的组织将时间花在赚钱的服务和功能上，或者，如果我们必须将更多功能扩展到宏体系结构基础架构，则将时间花在这些项目的回馈上。

Utilizing one of these service meshes will require us to understand it extremely well. We must be able to discern the implications it has upon our macro-architecture, and we must document those very carefully into our macro-architecture. Oh yes, even if you choose a service mesh, you must still write down a macro-architecture for your microservices infrastructure. These service meshes are only providing you an immense jump start, and, in some cases, answering some of the questions for you.

使用这些服务网格之一将需要我们非常了解它。 我们必须能够辨别它对我们的宏体系结构的影响，并且我们必须非常仔细地将其记录到我们的宏体系结构中。 哦，是的，即使您选择了服务网格，也仍然必须为微服务基础架构写下宏体系结构。 这些服务网格仅为您提供巨大的快速入门，并且在某些情况下，还会为您解答一些问题。

收盘时 (In Closing)

It has been an exciting time for me to get back to my very technical roots and dig deeper into modern architecture concepts through microservices. I look forward to continuing this journey, and I hope to hear from any of you who have done so and may have tips for me that I had not thought to include here. Thank you all for your attention, and I hope you got something out of this article.

对于我来说，回到我的技术根基并通过微服务更深入地研究现代体系结构概念真是令人兴奋的时刻。 我期待着继续这一旅程，并希望听到任何这样做的人，并且可能为我提供一些我没有想到的提示。 谢谢大家的关注，希望您从本文中学到一些东西。

I would like to close with a listing of the books I recently read in my quest for knowledge, one that I am currently reading, and two that I plan to read based on recommendations in other books and by multiple experts in software architecture.

I would like to close with a listing of the books I recently read in my quest for knowledge, one that I am currently reading, and two that I plan to read based on recommendations in other books and by multiple experts in software architecture.

The Tao of Microservices by Richard Rodger (The Tao of Microservices by Richard Rodger)

A great introduction to the world of microservices with a strong focus on the broad spectrum of requirements necessary to enter into this world.

A great introduction to the world of microservices with a strong focus on the broad spectrum of requirements necessary to enter into this world.

Richard starts with practical definitions and direction on how to build microservices followed by an overview of what it takes to run microservices.

Richard starts with practical definitions and direction on how to build microservices followed by an overview of what it takes to run microservices.

This book provides a good understanding of messages as transport, pattern matching for routing, and the large effort monitoring and measuring your environment will be.

This book provides a good understanding of messages as transport, pattern matching for routing, and the large effort monitoring and measuring your environment will be.

Warning: The author spends the first third of the book being rather derogatory towards any non-microservices approach to development. Read past that and he does have a good book.

Warning: The author spends the first third of the book being rather derogatory towards any non-microservices approach to development. Read past that and he does have a good book.

Microservices: Flexible Software Architecture by Eberhard Wolff (Microservices: Flexible Software Architecture by Eberhard Wolff)

This book is broken up into logical sections. The first two give a lot of repetitive background information on microservices presenting what they are, are not, and when you should and should not use them.

This book is broken up into logical sections. The first two give a lot of repetitive background information on microservices presenting what they are, are not, and when you should and should not use them.

There is a severe lack of commas in the book, which sometimes trips you up, but the material is very good. Part 3 turned this book into a complete winner for me when he began covering very specific pieces of information.

There is a severe lack of commas in the book, which sometimes trips you up, but the material is very good. Part 3 turned this book into a complete winner for me when he began covering very specific pieces of information.

Reading and Will Read List (Reading and Will Read List)

The following books are currently in my queue to read based on recommendations in the previous books and also by experts in software architecture.

The following books are currently in my queue to read based on recommendations in the previous books and also by experts in software architecture.

Martin Fowler is one such expert who quickly rose to the top in my searching and reading. His website is an invaluable resource as well.

Martin Fowler is one such expert who quickly rose to the top in my searching and reading. His website is an invaluable resource as well.

• Domain Driven Design by Eric Evans — I am currently reading this one, because literally everybody (even Object Thinking) references it. The deference it receives in the developer community is much like the Bible, and it shares a similar price tag. I am a third of the way through it, and it is definitely solidifying and putting names to practices I have used for some time. I look forward to more time with it.

  Domain Driven Design by Eric Evans — I am currently reading this one, because literally everybody (even Object Thinking ) references it. The deference it receives in the developer community is much like the Bible, and it shares a similar price tag. I am a third of the way through it, and it is definitely solidifying and putting names to practices I have used for some time. I look forward to more time with it.

• Building Microservices: Designing Fine-Grained Systems by Sam Newman. Martin Fowler speaks very highly of this one. It purports to “provide lots of examples and practical advice.” I understand many of the principles, and now I want to see more practical examples to further refine and firmly seat them.

  Building Microservices: Designing Fine-Grained Systems by Sam Newman. Martin Fowler speaks very highly of this one. It purports to “provide lots of examples and practical advice.” I understand many of the principles, and now I want to see more practical examples to further refine and firmly seat them.

• Production Ready Microservices by Susan J. Fowler. I believe Susan is going to drive more into this concept of a macro-architecture for microservices. In this article, I have attempted to do in brief what I hope she will do in much more detail.

  Production Ready Microservices by Susan J. Fowler. I believe Susan is going to drive more into this concept of a macro-architecture for microservices. In this article, I have attempted to do in brief what I hope she will do in much more detail.

How I Got Here (How I Got Here)

As I said in the opening, I have been on this mission for a couple of months. If you are interested in seeing the progression of my journey and possibly gain more insight into some of these topics, please peruse my earlier investigative posts:

As I said in the opening, I have been on this mission for a couple of months. If you are interested in seeing the progression of my journey and possibly gain more insight into some of these topics, please peruse my earlier investigative posts:

• Microservices: A Journey of Understanding

  Microservices: A Journey of Understanding

• Microservices: Early Thoughts Before That First Step

  Microservices: Early Thoughts Before That First Step

• Microservices Architecture: It Takes A Platform — Eureka!

  Microservices Architecture: It Takes A Platform — Eureka!

翻译自: https://www.freecodecamp.org/news/microservices-from-idea-to-starting-line-ae5317a6ff02/

hic染色体构想