monolith 架构_Monolith与微服务：哪种架构适合您的团队？
monolith 架构
by Jake Lumetta
杰克·卢米塔(Jake Lumetta)
Monolith与微服务：哪种架构适合您的团队？ (Monolith vs microservices: which architecture is right for your team?)
My good friend Darby Frey recently kicked off a greenfield project after assuming his new role as Sr. Platform Engineering Lead of Gamut. Despite starting out with monolith at his previous company Belly, he discovered that — in the right circumstances — starting with a monolith isn’t always the best way to go.
我的好朋友达比·弗雷(Darby Frey)在担任Gamut的高级平台工程主管之后，最近启动了一个绿地项目。 尽管在他以前的公司Belly中从整体开始，但他发现-在适当的情况下-从整体开始并不总是最好的方法。
At Belly, Darby and his team broke down their monolith into a fairly large microservices architecture. They managed to get it to a good place, but only after months of trials and tribulations migrating to microservices.
在Belly，Darby及其团队将其整体分解为相当大的微服务架构。 他们设法将它放到了一个好地方，但经过数月的试验和磨难，他们才迁移到微服务。
With this experience fresh in his mind, he approached his new project at Gamut a bit more cautious of microservices.
有了这种新鲜的经验，他对Gamut的新项目进行了一些谨慎的微服务。
“I was firmly a member of Team Monolith. [I thought] let’s build a single application and just pull things apart later if we start to feel pain,” he said.
“我坚定地是Monolith团队的成员。 (我认为)让我们构建一个应用程序，然后在我们开始感到痛苦时将其拆开。”他说。
While this was a greenfield project, Darby’s team was small, and he had aggressive timelines, so on the surface, a monolith seemed like the obvious choice.
尽管这是一个未开发的项目，但Darby的团队规模很小，而且他的时间表很激进，因此从表面上看，整体而言似乎是显而易见的选择。
“[But with this new project], I was anxious to not repeat the mistakes of the past.”
“ [但是有了这个新项目]，我急于不重蹈覆辙。”
And with that, he found himself faced with a decision we all struggle with: should we start with a monolith or microservices, and how do we decide?
这样一来，他发现自己面临着一个所有人都在为之奋斗的决定：我们应该从整体还是微服务入手，我们如何决定？
关于巨石的传统智慧 (Conventional Wisdom About Monoliths)
Many startups begin with a monolith, because its very structure lends itself well to small teams and offers other advantages like less operational overhead. Also, monoliths often just have one massive code base. Server side application logic, front end client side logic, background jobs, etc, are all defined in the same code base. This means that if developers want to make any changes or updates, they need to build and deploy the entire stack all at once.
许多初创企业都是从整体开始的，因为它的结构非常适合小型团队，并提供其他优势，例如运营开销更少。 而且，整体程序通常只有一个庞大的代码库。 服务器端应用程序逻辑，前端客户端逻辑，后台作业等均在同一代码库中定义。 这意味着，如果开发人员想要进行任何更改或更新，则需要立即构建和部署整个堆栈。
A monolith isn’t a dated architecture that we need to leave in the past. In certain circumstances, a monolith is ideal. I spoke to Steven Czerwinski, Head of Engineering at Scaylr and former Google employee, to better understand this.
整体不是过去我们需要离开的过时的体系结构。 在某些情况下，整体是理想的。 我与Scaylr的工程主管，前Google员工Steven Czerwinski进行了交谈，以更好地理解这一点。
“Even though we had had these positive experiences of using microservices at Google, we [at Scaylr] went [for a monolith] route because having one monolithic server means less work for us as two engineers,” he explained. This was back in the early beginnings of Scalyr.
他解释说：“即使我们在Google上拥有使用微服务的积极经验，但我们[在Scaylr]都采用了[整体式]途径，因为拥有一台整体式服务器对我们两名工程师来说意味着更少的工作，”他解释道。 这是在Scalyr的早期开始。
In other words, because his team was small, a unified application was more manageable in comparison to splitting everything up into microservices.
换句话说，因为他的团队很小，所以与将所有内容拆分为微服务相比，统一的应用程序更易于管理。
微服务的替代 (The Alternative of Microservices)
Zachary Crockett, CTO of Particle, told me this during an interview:
粒子技术总监Zachary Crockett在一次采访中告诉我：
“When discussing microservices, people tend to focus on one end of that spectrum: many tiny applications passing too many messages to each other. At the other end of the spectrum you have a giant monolith doing too many things. For any real system, there are many possible service oriented architectures between those two extremes.”
“在讨论微服务时，人们倾向于专注于这一范围的一端：许多微小的应用程序彼此之间传递过多的消息。 在频谱的另一端，您有一个巨大的整体，可以做很多事情。 对于任何真实的系统，在这两个极端之间有许多可能的面向服务的体系结构。”
The microservice architectural style is an approach to developing a single application as a suite of small services. Each runs in its own process and communicates with lightweight mechanisms, often an HTTP resource API.
微服务架构风格是一种将单个应用程序开发为一组小型服务的方法。 每个进程都在自己的进程中运行，并与轻量级机制(通常是HTTP资源API)进行通信。
These services are built around business capabilities and are independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and may use different data storage technologies.
这些服务围绕业务功能构建，并且可以通过全自动部署机制独立部署。 这些服务的集中管理几乎没有，它可以用不同的编程语言编写并且可以使用不同的数据存储技术。
Microservices do have distinct advantages:
微服务确实具有明显的优势：
Better Organization: Microservice architectures are typically better organized. Each microservice has a very specific job, and it is not concerned with the jobs of other components.
更好的组织：微服务架构通常组织得更好。 每个微服务都有一个非常具体的工作，它与其他组件的工作无关。
Decoupled: Decoupled services are also easier to recompose and reconfigure to serve the purposes of different apps (for example, serving both the web clients and public API). They also allow for fast, independent delivery of individual parts within a larger, integrated system.
分离：分离的服务也更易于重组和重新配置，以服务于不同应用程序的目的(例如，同时服务于Web客户端和公共API)。 它们还允许在大型集成系统中快速，独立地交付单个零件。
Performance: Under the right circumstances, microservices can also have performance advantages depending on how they’re organized. It’s possible to isolate hot services and scale them independently of the rest of the app.
性能：在适当的情况下，微服务还可以根据其组织方式而具有性能优势。 可以隔离热服务并独立于应用程序的其余部分扩展它们。
Fewer Mistakes: Microservices enable parallel development by establishing a hard-to-cross boundary between different parts of your system. By doing this, you make it hard — or at least harder — to do the wrong thing: namely, connecting parts that shouldn’t be connected, and coupling too tightly those that need to be connected.
更少的错误：微服务通过在系统的不同部分之间建立难以跨越的边界来实现并行开发。 这样，您将很难(或者至少很难)做错事：即，连接不应连接的零件，并将需要连接的零件紧紧地结合在一起。
But they also create unique challenges:
但是它们也带来了独特的挑战：
Cross-cutting Concerns Across Each Service: As you’re building a new microservice architecture, you’re likely to discover lots of cross-cutting concerns that you did not anticipate at design time. You’ll either need to incur the overhead of separate modules for each cross-cutting concern (i.e. testing), or encapsulate cross-cutting concerns in another service layer that all traffic gets routed through. Eventually, even monolithic architectures tend to route traffic through an outer service layer for cross-cutting concerns, but with a monolithic architecture, it’s possible to delay the cost of that work until the project is much more mature.
跨每种服务的跨领域关注点：在构建新的微服务体系结构时，您可能会发现很多在设计时未曾想到的跨领域关注点。 您要么需要为每个跨领域关注点(即测试)承担单独模块的开销，要么将跨领域关注点封装在所有流量都经过的另一个服务层中。 最终，即使是整体式体系结构也倾向于通过外部服务层路由通信，以解决跨领域的问题，但是采用整体式体系结构，有可能将这项工作的成本推迟到项目更加成熟之前。
Higher Operational Overhead: Microservices are frequently deployed on their own virtual machines or containers, causing a proliferation of VM wrangling work. These tasks are frequently automated with container fleet management tools.
更高的运营开销：微服务经常部署在其自己的虚拟机或容器上，从而导致VM争用工作激增。 这些任务通常使用集装箱车队管理工具自动执行。
哪种型号适合您？ (Which Model Is Right For You?)
Interviews with dozens of CTOs taught us that one approach does not fit all. Their experiences serve as a useful rubric for you to decide between a monolith and microservices. Answering these questions should guide you in the right direction:
与数十位CTO的访谈告诉我们，一种方法并不适合所有情况。 他们的经验为您在整体服务和微服务之间做出决定提供了有用的指导。 回答以下问题应指导您正确的方向：
您在熟悉的地区吗？ (Are You In Familiar Territory?)
Darby and his team at Gamut were able to delve directly into Microservices because he had experience with eCommerce platforms, and his company had a wealth of knowledge concerning the needs and demands of their customers. If he had been traveling down an unknown path, a monolith may have actually been the safer option.
Darby和他在Gamut的团队能够直接研究微服务，因为他具有电子商务平台的经验，并且他的公司对客户的需求和需求具有丰富的知识。 如果他一直在未知的道路上行驶，那么实际上可能是更安全的选择。
Similarly, startups are often born out of pains experienced at previous companies. In those scenarios, sometimes it’s quite clear that scaling is going to be a primary requirement, especially in infrastructure-based services like cloud log management.
同样，初创公司通常是从以前公司的经历中诞生的。 在这些情况下，有时很明显，扩展将是主要要求，尤其是在基于云日志管理等基于基础架构的服务中。
您的团队准备好了吗？ (Is Your Team Prepared?)
Does your team have experience with microservices? What if you quadruple the size of your team within the next year — are microservices ideal for that situation? Evaluating these dimensions of your team is crucial to the success of your project.
您的团队有微服务方面的经验吗？ 如果您明年将团队规模扩大两倍，该怎么办？微服务是否适合这种情况？ 评估团队的这些方面对于项目的成功至关重要。
Julien Lemoine, CTO at Algolia, chimed in on this point:
阿尔戈利亚(Algolia)首席技术官Julien Lemoine对此表示赞同：
“ We have always started with a microservices approach. The main goal was to be able to use different technology to build our service, for two big reasons:
“我们始终从微服务方法开始。 主要目标是能够使用不同的技术来构建我们的服务，这有两个主要原因：
1) We want to use the best tool for each service. Our search API is highly optimized at the lowest level and C++ is the perfect language for that. That said, using C++ for everything is a waste of productivity, especially to build a dashboard!
1)我们希望为每种服务使用最好的工具。 我们的搜索API在最低级别进行了高度优化，而C ++是实现此目的的理想语言。 就是说，使用C ++进行所有操作都会浪费生产力，尤其是构建仪表板时！
2) The want the best talents and using only one technology would limit our options. This is why we have different languages in the company, Go is less perfect than C++ when you want to optimize everything at the millisecond level but is the perfect language when performance is still key (processing of logs where we process several terabytes of logs per day, using ruby or python would be a waste of CPU).”
2)缺乏最好的人才，仅使用一种技术将限制我们的选择。 这就是我们公司使用不同语言的原因，当您要在毫秒级优化所有内容时，Go的效果不如C ++，但在性能仍然很关键的情况下，Go是完美的语言(处理日志，每天我们要处理几TB的日志) ，使用ruby或python将浪费CPU。”
If your team is prepared, starting with microservices is wise as it allows you to get used to the rhythm of developing in a microservice environment, right from the start.
如果您的团队已做好准备，那么从微服务开始是明智的，因为它使您从一开始就习惯了在微服务环境中进行开发的节奏。
您的基础设施如何？ (How’s Your Infrastructure?)
In reality, you’re going to need cloud-based infrastructure to make microservices work for your project. David Strauss, CTO of Pantheon, explained it thus:
实际上，您将需要基于云的基础架构来使微服务适合您的项目。 万神殿的首席技术官戴维·斯特劳斯(David Strauss)这样解释：
“[Previously], you would want to start with a monolith because you wanted to deploy one database server. The idea of having to set up a database server for every single microservice and then scale out was a mammoth task. Only a huge, tech-savvy organization could do that.
“ [以前]，由于要部署一个数据库服务器，因此您要从整体开始。 必须为每个微服务设置数据库服务器然后进行扩展的想法是一项艰巨的任务。 只有一个庞大的，精通技术的组织才能做到这一点。
Whereas today with services like Google Cloud and Amazon AWS, you have many options for deploying tiny things without needing to own the persistence layer for each one.”
如今，借助Google Cloud和Amazon AWS之类的服务，您可以有很多选择来部署微小的事物，而不必为每个事物拥有持久层。”
评估业务风险 (Evaluate The Business Risk)
You may think microservices is the “right” way to go as a tech-savvy startup with high ambitions. But microservices pose a business risk. David Strauss explained:
您可能会认为微服务是具有雄心壮志的精通技术的新兴公司的“正确”方法。 但是微服务会带来业务风险。 David Strauss解释说：
“A lot of teams overbuild their project initially; everyone wants to think their startup will be the next unicorn and that they should, therefore, build everything with microservices or some other hyper-scalable infrastructure. But that’s usually wrong, almost all the time.”
“许多团队最初都过度构建了他们的项目； 每个人都想以为自己的创业公司将是下一个独角兽，因此，他们应该使用微服务或其他一些可扩展的基础架构来构建一切。 但这通常都是错误的，几乎总是如此。”
One example of this from his early days at Pantheon was a system that was limited to a single VM. They thought it would be a month or two until they’d be forced to scale it. It ended up being over a year — and they ended up scaling it a completely different way than they had anticipated.
从他在Pantheon早期的时候就可以看到一个例子，该系统仅限于单个VM。 他们认为这将是一两个月，直到他们被迫扩大规模。 最终结束了一年多的时间，而他们最终以完全不同于预期的方式扩展了它。
He went on to say that, in these cases, the areas that you thought you needed to scale are probably not the parts that will need to scale first. This results in misplaced effort even for the systems that will need to scale.
他继续说，在这些情况下，您认为需要扩展的区域可能不是首先需要扩展的部分。 即使对于需要扩展的系统，这也会导致放错位置的工作。
上下文是关键—选择架构的经验法则 (Context is Key — Rules of Thumb For Choosing an Architecture)
We’ve taken hours of interviews with successful CTO’s and distilled them into general guidelines to follow when choosing your service architecture.
我们已经对成功的CTO进行了数小时的采访，并将其提炼为一般准则，以便在选择服务体系结构时遵循这些准则。
何时从整体开始 (When To Start With A Monolith)
Here are some scenarios that indicate that you should start your next project using monolithic architecture.
以下是一些场景，这些场景指示您应该使用整体架构开始下一个项目。
Your Team Is At Founding Stage: Your team is small, between 2–5 members, and is thus unable to tackle a broader and high-overhead microservices architecture.
您的团队处于创始阶段：您的团队很小，只有2至5名成员，因此无法应对更广泛的高开销微服务架构。
You’re Building An Unproven Product or Proof of Concept: Are you building an unproven product in the market? If it’s a new idea, it’s likely going to pivot and evolve over time, so a monolith is ideal to allow for rapid product iteration. Same applies to a proof of concept where your goal is just to learn as much as possible as quickly as possible, even if you end up throwing it away.
您要构建未经验证的产品或概念证明：您要在市场上构建未经验证的产品吗？ 如果这是一个新主意，它很可能会随着时间的推移而发展和演变，因此，整体式是理想的产品，可以实现快速的产品迭代。 这同样适用于概念证明，即您的目标是尽可能快地学习，即使最终您将其扔掉。
You Have No Microservices Experience: If your team has no prior experience with microservices, unless you can justify taking the risk of learning “on the fly” at such an early stage, it’s likely another sign you should stick to a monolith to start.
您没有微服务经验：如果您的团队以前没有微服务经验，除非您有理由在这么早的阶段冒着“即时”学习风险的理由，否则您可能应该坚持一个整体的另一个迹象。
何时开始使用微服务 (When To Start With Microservices)
Here are some scenarios that indicate that you should start your next project using microservices:
以下是一些场景，这些场景指示您应该使用微服务启动下一个项目：
You Need Quick, Independent Service Delivery: Microservices allow for fast, independent delivery of individual parts within a larger, integrated system. Note that, depending on your team size, it can take time to see service delivery gains versus starting with monolith.
您需要快速，独立的服务交付：微服务允许在大型集成系统中快速，独立地交付单个零件。 请注意，根据您的团队规模，与从整体开始相比，可能需要一些时间才能看到服务交付的收益。
A Piece of Your Platform Needs to Be Extremely Efficient: If your business is doing intensive processing of petabytes of log volume, you’ll likely want to build that service out in a very efficient language (i.e. C++) while your user dashboard may be built in Ruby on Rails.
您的平台的一部分需要非常高效：如果您的企业正在对数PB的日志量进行密集处理，则可能会在构建用户仪表板时以非常高效的语言(即C ++)来构建该服务。在Ruby on Rails中。
You Plan To Grow Your Team: Starting with microservices gets your team used to developing in separate small services from the beginning. And having teams separated by service boundaries makes it much easier to scale up your team when you need to without introducing exponential complexity.
您计划扩大团队：从微服务开始，使您的团队从一开始就习惯于开发单独的小型服务。 而且，通过服务边界将团队分隔开来，可以在不增加指数复杂性的情况下更轻松地按需扩展规模。
选择您可以舒适生活的架构 (Choose the Architecture You Can Comfortably Live With)
Microservices has become an increasingly popular service architecture, but it’s essential to understand whether it’s the best fit for your project. Your own context, evaluated against the above considerations, is the key to deciding if you should start with monolith or microservices.
微服务已成为一种越来越流行的服务体系结构，但是必须了解微服务是否最适合您的项目。 根据上述考虑进行评估的您自己的上下文是决定是从整体还是从微服务开始的关键。
Jake is the CEO of ButterCMS. For more content like this, follow @ButterCMS on Twitter and subscribe to our blog.
杰克是ButterCMS的首席执行官。 有关此类更多内容， 请在Twitter上关注@ButterCMS并订阅我们的博客 。
monolith 架构